Hmm, using this patch and setting m_bSendEqualNotifications to true doesn’t seem to make any difference. And looking at the code changes I can’t see why it would. In fact, the following just looks like a bug to me:
if( bUpStep )
{
nScrollPos -= nStepSize;
if( nScrollPos < _psbd.m_DSI.nMin || m_bSendEqualNotifications )
nScrollPos = _psbd.m_DSI.nMin;
} // if( bUpStep )
else
{
nScrollPos += nStepSize;
if( nScrollPos > nMx )
nScrollPos = nMx;
} // else from if( bUpStep )The extra check in the first part means that when m_bSendEqualNotifications is true, going up a line or page will ALWAYS set the scroll pos to the minimum. What’s that about? And whatever the logic, why isn’t something similar required for the line-down case?
What we need is to still receive scroll events, in particular we need SB_LINEDOWN and SB_LINEUP messages even when the scrollbar is already at the end, and these still don’t come through.
The only message we get now when trying to scroll past the end is SB_ENDSCROLL after the mouse is released
However, I have managed to work around the problem by manipulating the scrollbar range so we still get events when we need them.
I do still think it’s a bug though that events like SB_LINEDOWN are not forwarded through regardless of where the scroll thumb is. If the caller is handling such messages, then they will already be doing bounds checks and should know what they’re doing. For example, what if they wish to grow the scroll range upon attempts to scroll off the end?
But for now, we have a solution for our problem.
Thanks,
Rob.