Well, I hope it is released properly. I accidentally clicked on
something "sticky" and it confused me a bit. So samples/BitmapScroll.pl
may have gotten more rearranged than necessary, but I think it is back
in order now. It seems to work, anyway.
On approximately 9/30/2004 6:25 PM, came the following characters from
the keyboard of Glenn Linderman:
Hmm. One could argue that it is purely the responsibility of the user
code that calls Win32::Scroll from the -onScroll handler, to adjust the
position as appropriate.
It seems (confirm this if you can Jez) that the "issues" probably only
occur for SB_THUMBPOSITION and SB_THUMBTRACK operations, as these are
the only that use the position value which is potentially from the
WM_HSCROLL or WM_VSCROLL message.
To allow easier "plumbing", and for the sake of efficiency, I'm adding a
special value to the "position" parameter, of -1, which means "use the
value from GetScrollInfo nTrackPos instead of the passed in value. So
user code that directly calls Scroll($hv,SB_THUMBPOSITION,$pos) without
receiving a message will still work, but user code that says
-onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
$win->Scroll( $sb, $op, $pos, 1 );
$win->InvalidateRect( 0 );
),
need only be recoded as
-onScroll => sub { my ( $wh, $sb, $op, $pos ) = @_;
$win->Scroll( $sb, $op, -1, 1 );
$win->InvalidateRect( 0 );
),
to cause the -onScroll to use the value retrieved by the internal call
to GetScrollInfo that it has to make anyway... thus avoiding doing two
calls. The GetScrollInfo does have to have a different flag setting to
retrieve the number. I haven't tested this with numbers that exceed 16
bits, but it seems to not break anything for smaller numbers.
I guess I've found the "off-by-one" error.... the SCROLLINFO struct is
defined to have the "min and max" values for scrolling. This
inconsistency with the graphics ops, which use "min and max+1" for all
their bounds, is apparently another idoit-syncracy of the Windows API.
So I'm updating the sample/BitmapScroll.pl as follows:
Alter Scroll to be simpler, and use Win32::GUI::Scroll internally, and
to return 1, as appropriate for use as an event sub.
Alter OpenBitmap to use bitmap size-1 for the ScrollRange maximums.
Alter Paint to pass $win->GetClientRect as the 1st 4 parameters, rather
than invoking GetWindowRect twice, and after all, it is the ClientRect
we want to fill, not the WindowRect...
Alter Resize to call AdjScroll, which does more complex adjustments to
sizes and positions based on the presence or absence of scrollbars.
AdjScroll is also needed to set up the scrollbars in OpenBitmap, to get
it done accurately. The +20 technique works, to a degree, but this is
more precise (I've been using this change for quite a while, and it
works great... but is probably what made me aware of the off-by-one error).
I've also extracted a more generic OpenBitmap functionality, because
there are other ways one might obtain the bitmap than asking the user...
so I've renamed the "user interface" part FindAndOpenBitmap, and the
generic code OpenBitmap. The more generic OpenBitmap also permits
substitution of a different bitmap of the same size without altering the
scroll positions, which is a function I find handy.
I'm about to release all this.... of course it can be rolled back if it
is anathema. But it all seems better, and seems to work for me, both in
the sample program, and in my two applications that both use the same
technology -- derived from the sample originally (thanks Jez) and then
refined -- and now put back into the sample.
On approximately 9/30/2004 10:11 AM, came the following characters from
the keyboard of Glenn Linderman:
TADA!
As I mentioned to Jez off-list, the WM_HSCROLL and WM_VSCROLL messages
come with parameters that are 16-bit... but the definition of
scrollbars allows 32-bit numbers, if Get/SetScrollInfo APIs are used.
Jez was noticing these issues when scroll ranges got into the 100,000+
range, he mentioned off-list.
So I perused the code for scrolling, and it seems that the incoming
scroll message parameters are preserved and passed to the default
Scroll event, with uses them.
There are two possible solutions. I prefer the 2nd.
1) In all the places where WM_HSCROLL and WM_VSCROLL events are
received (several .xs modules) the message parameter could be replaced
by the real 32-bit value from a GetScrollInfo call, before calling the
Scroll event.
2) In all the places where the Scroll event is processed, it should be
the user responsibility to use Get/SetScrollInfo instead. For
Win32::GUI, this means that the default Scroll event in GUI.xs should
be updated.
The reason I prefer the second is that it preserves the Windows
idoit-syncracies, which are (reasonably well) documented in MSDN; that
it is less GUI code to change, and in a more central place; and that
users should be used to using Get/SetScrollInfo in their own code
anyway, due to MSDN documentation.
Comments?
I'll start working on a patch to GUI.xs Scroll function.... along the
way, I'm looking for the off-by-one error... gotta be in there
somewhere...
On approximately 9/30/2004 8:09 AM, came the following characters from
the keyboard of Jez White:
As a quick reply, I have noticed other 'issues' with scrolling,
typically when large values are used for the scroll range, I'm not
sure if it's a win32::gui thing, a windows thing or a bug- it might
or might not be related to issue you've highlighted.
Cheers,
jez.
----- Original Message ----- From: "Glenn Linderman" <[EMAIL PROTECTED]>
To: "Jez White" <[EMAIL PROTECTED]>
Cc: "Laurent ROCHER" <[EMAIL PROTECTED]>;
<perl-win32-gui-hackers@lists.sourceforge.net>
Sent: Thursday, September 30, 2004 3:57 PM
Subject: Re: [perl-win32-gui-hackers] Main Commit
Now you know I'm not really a Windows GUI expert. I'm going to
look now at updating my applications in the same manner as Laurent
updated the sample code.
But I've recently noticed something in the sample bitmap scrolling
code, which I am gratefully using in a couple of my applications,
which is more obvious when displaying Black & White line art that
extends to the very edge of the BMP, rather than full-color images,
although once you know to look for it, it can be seen with
full-color images also.
When scrolling to the complete right/bottom of a bitmap in a smaller
window, especially when scrolling via "pages" by clicking on the
empty area of the scroll bar, it becomes clear that the
right-/bottom-most column/row of pixels in the window does not get
redrawn at the very end. It is like there is an off-by-one error
somewhere in the code.
Now I notice the scrolling limits are based on Win32::GUI::Width,
and that Win32::GUI::Width calculates width as Right-Left. Now I
don't know the Windows spec well enough to know if it should be
Right-Left+1 -- in other words, in Right the last drawable pixel, or
the first non-drawable pixel? Of course, maybe the off-by-one error
is somewhere else instead; this possible source of the off-by-one is
just speculation on my part that I haven't yet confirmed or
discarded by reading the Windows documentation. But the scrolling
bug exists, regardless of where the off-by-one error creeps in.
On approximately 9/30/2004 12:01 AM, came the following characters
from the keyboard of Jez White:
Hi,
I've just tested the changes to the -onpaint event and it looks
good:)
Cheers,
jez.
----- Original Message -----
*From:* Laurent ROCHER <mailto:[EMAIL PROTECTED]>
*To:* perl-win32-gui-hackers@lists.sourceforge.net
<mailto:perl-win32-gui-hackers@lists.sourceforge.net>
*Sent:* Wednesday, September 29, 2004 10:22 PM
*Subject:* [perl-win32-gui-hackers] Main Commit
Hi,
Changelog
- MakeFile.pl, MakeFile_m.pl
+ Use tab as space in rule for use with dmake
- GUI.pm, GUI.xs
+ Add -brush option for Win32::GUI::Class.
- GUI_Helper.cpp
+ classname_From and handle_From : Replace strlen as
static
string length.
- Window.xs, GUI_MessageLoops.cpp, Samples\BitmpaScroll.pl :
+ Move Paint event in Window_onEvent.
+ Use DoEvent_Paint function like Graphic
- ToolTip.xs :
+ Add -balloon option
Laurent.
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on
ITManagersJournal
Use IT products in your business? Tell us what you think of them.
Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Perl-Win32-GUI-Hackers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them.
Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Perl-Win32-GUI-Hackers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
