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? 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. 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? > > 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. Cheers, jez.
