1. win32lib scrollbar bugs
This is a multi-part message in MIME format.
------=_NextPart_000_3e97_78a8_5e3d
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.
Scrollbars built into windows are even worse. They limit you to
100, which is really rediculous and makes these scrollbars
virtually useless.
regards,
Daryl Van Den Brink
------=_NextPart_000_3e97_78a8_5e3d
Content-Type: text/plain; name="Scroll.exw"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="Scroll.exw"
include win32lib.ew
constant
win1 = createEx(Window, "win1", 0, 0, 0, 400, 270, WS_HSCROLL, 0),
lblWinScroll = create(LText, "win1 scroll pos: 0", win1, 0, 200, 100, 30,
0),
scrlHScroll = create(HScroll, "", win1, 0, 60, 350, 20, 0),
lblHScroll = create(LText, "HScroll pos: 0", win1, 0, 80, 100, 30, 0)
setWindowScrollRange(win1, SB_HORZ, 0, 200, 10)
setScrollRange(scrlHScroll, 0, 100000)
procedure win1_onScroll(integer self, integer event, sequence params)
setText(lblWinScroll, sprintf("win1 scroll pos: %d",
{getHScrollPos(win1)}))
end procedure
setHandler(win1, w32HScroll, routine_id("win1_onScroll"))
procedure scrlHScroll_onScroll(integer self, integer event, sequence params)
setText(lblHScroll, sprintf("HScroll pos: %d", params))
end procedure
setHandler(scrlHScroll, w32HScroll, routine_id("scrlHScroll_onScroll"))
WinMain(win1, Normal)
------=_NextPart_000_3e97_78a8_5e3d--
2. Re: win32lib scrollbar bugs
Don wrote:
> > 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.
>From win32 reference:
Note that the WM_VSCROLL message carries only 16 bits of scroll box position
data. Thus,
applications that rely solely on WM_VSCROLL (and WM_HSCROLL) for scroll position
data have
a practical maximum position value of 65,535.
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
3. Re: win32lib scrollbar bugs
Hi,
That is not a bug in win32lib.... u have the option of changing that value
in win32lib. Its also more importantly there to easily handle progressbar
scrolls.
It is MS' fault for not updating the scrollbar... i mean the progress
bar suffers the same but in later version of comctl32 (ver 4.70 and above)
PBM_SETRANGE32 was introduced to allow 32 bit values for scroll range.
I hope Derek adds this fix to win32lib since 96% of euphorians use
comctl32 4.7 and above.
This is a very known issue to microsoft so don't blame win32lib. U can
still do some calculations to solve this bug. eg u make to every 1 scroll of
the thumb....get scroll*ratio... That was my first work around to progress
bar setrange.
Jordah
----- Original Message -----
From: <daryl_vdb at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 03, 2003 7:13 AM
Subject: 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
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
---
4. Re: win32lib scrollbar bugs
The whole reason I had questions about PushButtons is because I am working on a
Scroll2 control
which is a custom scroll control. Once I'm able to move a button around the
window, it'll be all
down hill from there!
~Greg
g.haberek at comcast.net
----- Original Message -----
From: <jordah at btopenworld.com>
Subject: Re: win32lib scrollbar bugs
Hi,
That is not a bug in win32lib.... u have the option of changing that value
in win32lib. Its also more importantly there to easily handle progressbar
scrolls.
It is MS' fault for not updating the scrollbar... i mean the progress
bar suffers the same but in later version of comctl32 (ver 4.70 and above)
PBM_SETRANGE32 was introduced to allow 32 bit values for scroll range.
I hope Derek adds this fix to win32lib since 96% of euphorians use
comctl32 4.7 and above.
This is a very known issue to microsoft so don't blame win32lib. U can
still do some calculations to solve this bug. eg u make to every 1 scroll of
the thumb....get scroll*ratio... That was my first work around to progress
bar setrange.
Jordah
----- Original Message -----
From: <daryl_vdb at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 03, 2003 7:13 AM
Subject: 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
>
>
> TOPICA - Start your own email discussion group. FREE!
>
---
TOPICA - Start your own email discussion group. FREE!
5. Re: win32lib scrollbar bugs
>That is not a bug in win32lib.... u have the option of changing that value
>in win32lib.
That's exactly what my demo program does. It still limits you to 100.
Try it yourself. This only affects windows, not scrollbar controls.
I realise that microsoft were stupid enough to use a 16-bit unsigned int
somewhere in windows, but I thought that if that was the case, it wouldn't
allow you to scroll past 65535 with the buttons either. Try it for
yourself: drag the scrollbar to some position just before 65536, then use
the button at the end of the scrollbar to move it further along. If you
do this, it will go past 65536. I know this is also a bug in windows
and I'm not blaming win32lib, but it is wierd behaviour. It also puzzles
me as to why windows would let me set 32 bit scroll ranges.
Anyway, Derek says that the latest win32lib will support 32 bit scroll
ranges, which I am thankful for.
regards,
Daryl Van Den Brink
