Hi,
Graphic control it's a specialized window for painting issue.
Graphic was created only for provide Paint event for user wanted to draw
specific stuff.
Paint event, it's not usefull for standard/common control (button,
listbox, ...). And, for doing owner draw control, it's not WM_PAINT event to
use but WM_DRAWITEM/NM_CUSTOMDRAW.
For me, it's not a good idea to add this event for all control.
If you really need this event for a special case, it's better to use
HookEvent.
For performance, WM_PAINT it's a frequent event so adding it to every
control can slowdown application.
But, It's a good idea to add -onEraseBkGnd event to Graphic control.
Laurent.
>
> 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?
>
