Menu
▾
▴
Re: [perl-win32-gui-hackers] Main Commit
|
From: Glenn L. <pe...@ne...> - 2004-10-01 02:46:40
|
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" <pe...@ne...>
>>> To: "Jez White" <je...@je...>
>>> Cc: "Laurent ROCHER" <ro...@cl...>;
>>> <per...@li...>
>>> 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:ro...@cl...>
>>>>> *To:* per...@li...
>>>>> <mailto:per...@li...>
>>>>> *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
>>>> Per...@li...
>>>> 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
>>> Per...@li...
>>> 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.
|
