How do I figure out why a WM_PAINT message was sent to my app?

[Finn Arildsen]

I have a minor issue with my MFC application that puzzles me.

Whenever the application becomes the active and gets focus, it gets painted
etc ... normal behaviour.
However, approx. 5 sec later, the main window gets a WM_PAINT message (or
sometimes two) and repaints itself.

There is no need for this repainting, it only causes a brief flicker.

I would like to figure out what causes the WM_PAINT message to be sent to
the application. It is probably my own fault, and I would like to fix it
if I could.

So far, I haven't been able to find the culprit. I have searched all over
my source code for an irrate Invalidate call that could case the application
to repaint, but none of the breakpoints I set have triggered.

So here is the question: I can - of course - set a breakpoint that triggers
when the WM_PAINT message is handled. Is there any way to backtrack from
there to the source that caused the WM_PAINT to be sent - or in any other
way identify the reason for the WM_PAINT?

Any help is appreciated

Thanks,
Finn A.


BTW, it's an MDI application - I'm not sure if this is of any significance

[P.GopalaKrishna]

Hello,

Are you handling the setfous event anywhere? Or check if the UpdateUI()
functions for any menus are the reason for this.

Also check the lpRect that is being requested to be repainted. Perhaps it
could give some clue.

P.Gopalakrishna.
http://www.geocities.com/krishnapg/

Post by Finn Arildsen
I have a minor issue with my MFC application that puzzles me.
Whenever the application becomes the active and gets focus, it gets painted
etc ... normal behaviour.
However, approx. 5 sec later, the main window gets a WM_PAINT message (or
sometimes two) and repaints itself.
There is no need for this repainting, it only causes a brief flicker.
I would like to figure out what causes the WM_PAINT message to be sent to
the application. It is probably my own fault, and I would like to fix it
if I could.
So far, I haven't been able to find the culprit. I have searched all over
my source code for an irrate Invalidate call that could case the application
to repaint, but none of the breakpoints I set have triggered.
So here is the question: I can - of course - set a breakpoint that triggers
when the WM_PAINT message is handled. Is there any way to backtrack from
there to the source that caused the WM_PAINT to be sent - or in any other
way identify the reason for the WM_PAINT?
Any help is appreciated
Thanks,
Finn A.
BTW, it's an MDI application - I'm not sure if this is of any significance