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.
