getting flooded with WM_PAINT events

Started by
2 comments, last by InetRoadkill 9 years, 1 month ago

I created a simple MFC project using VS2013, then overloaded WinApp::Run() with a sample message pump taken from MSDN example code. I added code to the message pump that was to be called every time there was an Idle. However, what I found was that the idle code never gets called. Further investigation revealed that the message pump was being flooded with WM_PAINT events which was preventing it from ever going idle. My question is why is my app being flooded with WM_PAINT events? I'm not calling anything to invalidate the window or indicate that I want the window to be redrawn. The window has been set up to handle openGL rendering. I'm not sure if that is a factor or not.

Advertisement
I found a relevant SO thread that might be helpful to you:

http://stackoverflow.com/questions/2842319/swapbuffers-causes-redraw

I think you're on the right track with the SwapBuffer triggering a new WM_PAINT event. However, the sample code in the SO link doesn't fit the messaging used in Win7. (Or maybe I'm using the wrong one.) VS2013 provided an OnPaint function which has no return codes ( void OnPaint() ), so there's no way to signal the paint event was handled.

Aha. This fixed the problem. (Added to the window handling the OGL rendering):

BOOL CChildView::PreTranslateMessage(MSG* pMsg)
{
if (pMsg->message == WM_PAINT)
{
return TRUE;
}

return FALSE;
}

This topic is closed to new replies.

Advertisement