• Advertisement
Sign in to follow this  

getting flooded with WM_PAINT events

This topic is 1151 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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.

Share this post


Link to post
Share on other sites

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;
}

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement