Re: [perl-win32-gui-hackers] GUI.xs (BeginPaint and EndPaint)

[Glenn L. <pe...@ne...>]

On approximately 5/18/2004 7:49 AM, came the following characters from
the keyboard of Jez White:
> Ok, I've done some more digging and reading of Win API (is it just me, or
> does internet explorer freeze now and again when looking at MS
> documentation?)
> 
> I had  assumed that the Graphic control was some sort of windows thing. It's
> not, its a perl thing. A graphic is simply a window, with XS code to call
> the paint and interactive events in perl. I must admit that other than the
> paint handler, I'm a bit stumped to come up with a reason why the Graphic
> control exits, other than in older versions of Win32::GUI normal windows did
> not have the events associated with an "interactive" Graphic (mousemove
> etc). So if a normal window had a paint handler, why use a graphic control?

Perhaps so that it is a "widget" instead of a "window"?  (In perl speak, 
not Windows speak.)

> It also turns out there is an alternatives to using Windows
> BeginPaint/EndPaint - use ValidateRect and GetUpdateRect which is how
> painting works for Graphic controls (ValidateRect is Validate in Perl
> speak). There are subtle differences to BeginPaint/EndPaint and
> ValidateRect/GetUpdateRect but I'll have to play to see what the effects are
> in reality. You can use the Validate method on a DC for a hooked paint
> event.

Hmm.  TMTOWTDI.  When there is only one known way, one just attempts to 
solves all problems in terms of that one way.  And one learns enough to 
do that, but maybe never comes to a true understanding of that one... 
one could just have "rote sequences" for doing desired things.  However, 
once one becomes aware of a second way to do things, then one must 
puzzle out a deeper understanding of the original way, as well as the 
new way, so that one can understand and choose which way is best for 
which solutions.  One probably learns more when TMTOWTDI.

> If adding an -onPaint event is a sensible thing (I think it is) I also
> suggest adding the event -onEraseBkGnd  (WM_ERASEBKGND). Having this event
> would give more control in how the background is erased (that annoying
> flicker on resize). My only concern is would this effect the performance of
> windows who do not explicitly use these events?

Well, all the events come into the GUI XS event messageloop.  So the 
more cases there are to test for, the slower all events become.  I think 
that is why the bitmap exists... for a quick check on the likelihood 
that there is a Perl function to be called for this event, or not.

I would think it is reasonable to bundle WM_ERASEBKGRND and WM_PAINT 
into the same bit of the bitmap, because they are likely to be used or 
disused, for the same windows (bits in the bitmap are a scarce resource)

But I don't think the addition of an extra event to check for would be a 
significant slowdown to all windows, unless much code is added just to 
determine whether or not it is "this event", and that is typically done 
with the switch statement, and the cost of an extra case in a switch 
statement, while not zero, is not generally high overhead.

>>>There were two new functions added not
>>>to long ago that may help with keystrokes, GetKeyboardState and
>>>GetAsyncKeyState. I've managed to get pseudo accelerator keys working on
>>>individual controls with them.
>>
>>Maybe there's some sample code lurking within your application there :)
> 
> I'll try and put an example together.

Thanks.

-- 
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.