[solved] Dead lock in code peeking for WM_PAINT

We have encountered certain cases where we dead lock the app due to code that looks like this:

        MSG msg;
        while (::PeekMessage(&msg, NULL, WM_PAINT, WM_PAINT, PM_NOREMOVE))
        {
            if (!GetMessage(&msg, NULL, WM_PAINT, WM_PAINT))
                return;
            DispatchMessage(&msg);
        }

In earlier versions of CJ, CXTPPopupControl had such a construct but it since been removed. We have been changing any code we have that does the above to use PM_REMOVE and removing the GetMessage call altogether. Depending on the window, you may or may not be able to remove the loop itself - most of this code will capture the mouse and after the peek look it calls GetMessage and if it isn't a mouse message DispatchMessage is called anyways. But for some windows, trailers are left on the screen that don't get repainted until the user lets up on the mouse.

In any case, with 16.3 CJ I still see a few places where this loop exists so there is the potential for a lockup. CJ might want to examine, e.g., CXTPDockingPaneContext::InitLoop. If m_bUseAlphaContext is false (for one of two reasons I could find), that look exists. I see the loop in CXTPTabClientWnd as well as the docking context. ITs in the XTPFlowGraphControl but we don't use that.

We started hitting this because we added a facebook UI element in our app (using the web browser control) and when a facebook timeline loads in the web page, any code that enters that loop has a high probability of locking up as the user moves the window (resizes, moves splitter etc.). It appears something in another thread is causing the WM_PAINT message to go missing between the main threads call to PeekMessage and the call to GetMessage in that loop (I didn't figure out where the WM_PAINT went to so that is supposition on my part).

In any case, it appears that with the popup control, CJ made the change a long time ago and I assume they noticed this too. Seems to be "standard" stuff as I found code we have for toolbars that is 20 years old that does the same thing.

Good news, the problem has been fixed in all places where pending WM_PAINT messages are processed. The changes will be available in the upcoming update.