1. RE: win32lib scrollbar bugs
> to Derek Parnell (and others)
>
> Win32lib seems to have a problem with scrollbars that have long
> ranges. I have included a small test program which exposes this
> bug. When the scroll range is set to anything over 65535, win32lib
> won't let you use the whole scrollbar. Try this for yourself to
> see what I mean. You can still use the arrows to scroll past
> 65535, but if you drag the scrollbar and watch the number under it,
> you'll notice that they skip back to 0.
This behaviour is not related to Win32Lib or any bug...
Microsoft (in their infinite wisdom) decided the messages that indicate
scroll bar position, WM_HSCROLL and WM_VSCROLL, are limited to 16 bits
of position data (65535 max). I am not aware of any reliable work
around apart from creating a custom scroll bar control.
Don
2. RE: win32lib scrollbar bugs
> 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
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
3. RE: win32lib scrollbar bugs
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
>
4. RE: win32lib scrollbar bugs
>This behaviour is not related to Win32Lib or any bug...
>
>Microsoft (in their infinite wisdom) decided the messages that indicate
>scroll bar position, WM_HSCROLL and WM_VSCROLL, are limited to 16 bits
>of position data (65535 max). I am not aware of any reliable work
>around apart from creating a custom scroll bar control.
>
>Don
It looks like I'll have to create a custom control. My wave editor
program will require very long scrollbar ranges for large files.
Acrually, I did find the cause of the bug for window scrollbars.
In function NewControl:
window_range[id] = {0, 100}
change it to {0, 65535} and youll get full use of the scrollbar.
This is definitely a bug in win32lib.
regards,
Daryl Van Den Brink
