1. RE: win32lib scrollbar bugs (For library developers)
- Posted by Al Getz <Xaxo at aol.com> Feb 03, 2003
- 452 views
daryl_vdb at hotmail.com 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. > > 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 > > My guess is that win32lib just needs a 32 bit scrollbar update There certainly is a way to scroll 32 bit in windows 95 and up, but there is a minor bug in some versions of windows which prevents doing things exactly the way the official documentation might lead you to believe. First off, forget about: SetScrollPos, SetScrollRange, GetScrollPos, and GetScrollRange. Basically, forget they exist The two functions to use are: 1. GetScrollInfo() 2. SetScrollInfo() These two functions provide the 32 bit interface for windows scrollbars. If you try to use any other functions, something wont work the way you expect it to. There is a bug in some windows versions so you MUST use SIF_ALL with the SCROLLINFO struct. Any other value might cause the nTrackPos member to become invalid. For reference when programming in Euphoria: SIF_ALL = (SIF_RANGE | SIF_PAGE | SIF_POS | SIF_TRACKPOS) where SIF_PAGE = 0x0002 SIF_POS = 0x0004 SIF_RANGE = 0x0001 SIF_TRACKPOS = 0x0010 You will process: iMsg = WM_VSCROLL or iMsg = WM_HSCROLL If i remember right, I dont think nPos is valid when the user drags the thumb, but nTrackPos is. In any case, you dont want to use any other functions because they wont support the case when the user drags the thumb (32bit). My editor uses this technique and has been tested with hundreds of thousands of lines of text and way over 100MB of text. The scrolling is per line, not per pixel, but more then 65536 lines of text will still require the use of the 32 bit scrolling technique. Good luck with your programming, Al
2. RE: win32lib scrollbar bugs (For library developers)
- Posted by Don Phillips <EuNexus at yahoo.com> Feb 04, 2003
- 492 views
> My guess is that win32lib just needs a 32 bit scrollbar update > > There certainly is a way to scroll 32 bit in windows 95 and up, but > there is > a minor bug in some versions of windows which prevents doing things > exactly > the way the official documentation might lead you to believe. > > First off, forget about: > > SetScrollPos, SetScrollRange, GetScrollPos, and GetScrollRange. > Basically, forget they exist > > The two functions to use are: > 1. GetScrollInfo() > 2. SetScrollInfo() > > These two functions provide the 32 bit interface for windows scrollbars. > If you try to use any other functions, something wont work the way you > expect it to. > > There is a bug in some windows versions so you MUST use SIF_ALL > with the SCROLLINFO struct. Any other value might cause the > nTrackPos member to become invalid. > > For reference when programming in Euphoria: > SIF_ALL = (SIF_RANGE | SIF_PAGE | SIF_POS | SIF_TRACKPOS) > where > SIF_PAGE = 0x0002 > SIF_POS = 0x0004 > SIF_RANGE = 0x0001 > SIF_TRACKPOS = 0x0010 > > You will process: > > iMsg = WM_VSCROLL or iMsg = WM_HSCROLL > > If i remember right, I dont think nPos is valid when the user drags > the thumb, but nTrackPos is. > > In any case, you dont want to use any other functions because they wont > support the case when the user drags the thumb (32bit). > > My editor uses this technique and has been tested with hundreds of > thousands > of lines of text and way over 100MB of text. The scrolling is per line, > not per pixel, but more then 65536 lines of text will still require the > use of > the 32 bit scrolling technique. > > > Good luck with your programming, > Al Ah ha! I *knew* there was a work around, I just could never find it... Thanks for clearing that up. It will certainly come in handy some time down the road. Don