The answers to those two questions are: yes and no. Robin has told you the
correct answer twice, but I don't think he has really explained WHY this
happens. Allow me.
On Windows, when all or part of a window needs repainting, Windows notes this
by storing the coordinates of the "dirty" rectangle in the window data
structures. When the main message loop in a Windows program calls
GetMessage, if there are no other messages outstanding, it checks the dirty
rectangle. If it is not empty, it will trigger a WM_PAINT message.
However, the dirty rectangle is only cleared when you call the
BeginPaint/EndPaint APIs (which is what wxPaintDC does). If you never call
EndPaint, then the dirty rectangle is still there, and the next cycle through
your message loop will fire another WM_PAINT message.
THAT'S where your infinite loop comes in. If you handle WM_PAINT, you must
either instantiate a wxPaintDC or call evt.Skip().
ยทยทยท
On Mon, 13 May 2002 20:34:36 -0400, "Steve Holden" <sholden@holdenweb.com> wrote:
[Steve]
> Well, I've verified that it's a stream of EVT_PAINT events that are
> causing the high utilisation (I just registered an event handler that
> printed a message). However, I'm not sure what the protocol for
> switching the events off might be - when EVT_PAINT calls the event's
> .Skip() method the CPU hits the stop at 100%, but I only see two
> EVT_PAINT events. When I *don't* call it I see a continuous stream of
> EVT_PAINT events and the window doesn't even
> get completely drawn.[Robin]
Calling evt.Skip() allows the default handler to run, which does create
the wxPaintDC, so the problem doesn't happen.[Steve]
Am I doing something wrong? Would moving to 2.3.3pre3 help?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.