OpenEuphoria

RE: win32lib scrollbar bugs

• Posted by Mike <vulcan at win.co.nz> Feb 03, 2003
• 490 views

Don,

What this all means (as you know) is that when a scroll bar is being 
dragged the (32-bit) position value will not be known. However, when the 
user stops dragging (& releases the mouse button) the position can be 
accurately known, using getScrollPos(), and the application can then 
update the display to reflect a 32-bit position value.

In this instance I believe the message to trap is SB_ENDSCROLL which 
tells the application that the scrolling has finished.

So, the technique *could* be useful but only if the user is willing to 
accept this (irritating) behaviour. Some older applications I have will 
update the display only after the scroll bar has been released, eg: the 
application that opens .hlp files.

I have half a mind to programmatically simulate a greater-then-16-bit 
position value for real-time scrolling in my new Win32 library. I just 
might do it one day when I find the other half 


Mike.


Don Phillips wrote:
> Yes, it is interesting to see them state it can be circumvented, and in 
> the same mouthful also state:
> 
> <quote>
> The limitation on this technique applies to real-time scrolling of a 
> window's content. An application implements such scrolling by processing 
> 
> the WM_HSCROLL or WM_VSCROLL messages that carry the SB_THUMBTRACK 
> notification message, thereby tracking the position of the scroll box, 
> also known as the thumb, while the user moves it. Unfortunately, there 
> is no function to retrieve the thumb's 32-bit position while the user 
> moves it. GetScrollPos provides static position data only; an 
> application can therefore only obtain 32-bit position data before or 
> after a scroll has taken place.
> <end quote>
> 
> So how can it be circumvented?
> 
> I fail to see of what use the 32 bit value has when it cannot be 
> determined while the user moves it... only before or after its moved.  
> To me this defeats the purpose of the scroll bar itself.
> 
> Don


> > However, because the SetScrollPos, SetScrollRange, GetScrollPos, and 
> > GetScrollRange
> > functions support 32-bit scroll bar position data, there is a way to 
> > circumvent the 16-bit
> > barrier of the WM_HSCROLL and WM_VSCROLL messages. See GetScrollPos for 
> > a description of
> > the technique and its limits.
> > 
> >     Martin
>