CXTPPopupControl, skins and Office2013 theme

We have a window derived from CXTPPopupControl. Originally the CXTPPopupControl::TrackMove method had code that dispatched all WM_PAINT messages near the top of the method. That code was removed a number of versions ago.

while (GetCapture() == this )
{
        MSG msg;

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

Without this code, when I move my window, especially over the ribbon area (groups area in particular), there is a constant stream of un-updated areas on the ribbon bar. The display doesn't update until I quit moving the window. It looks terrible.

So we put this code into our class and that fixed this display problem. But now I think I know why this code was removed by CodeJock. If I skin the application using CJ skinning, the app locks up when I go into that loop if I have a combobox child window in the popup control. I stepped thru a ton of call frames to see why I was locking up and when DispatchMessage for WM_PAINT is called I found OnCtlColor just keeps getting called for dialog containing the combobox as the "CodeJock themed combobox" code is trying to draw the control. That is, DispatchMessage is called for WM_PAINT and I am hosed as that call never returns. If I remove that loop, we don't completely lock up when using skins but some of the controls on the popup get a constant stream of WM_UPDATEUISTATE messages as seen by Spy++. I didn't determine the exact reason or the lockup but I never got out of the "hooking" code that is redirecting the message processing. I have stepped out of the CJ call frames after OnCtlColor is called and deep into Windows code (assembly mode) and in Windows "pfnDispatch"ing code, when I try to "step out" of the frame, I get back to the CDialog::OnCtlColor where I have a breakpoint again for the same combobox. It is almost as if a hook isn't removed when it should be. So I cannot use skins due to that issue (I posted this lockup problem on the skins forums).

Now I have added code to support the Office2013 ribbon theme as we have given up on CodeJock skins for now as they simply don't work with the popup window. I load the Office2013 ribbon them using "white" INI and that same popup window comes up with a transparent/translucent background and when the window is displayed, some of the static text boxes are corrupted - they pick up pixels of what is under the static text window's background when it first displays and that data remains for the life of the window (moving doesn't fix the display but it doesn't cause more pixels from under the window to be pulled into the popup window either). This occurs even if I have our OnLButtonDown code call the CXTPPopupControl::OnLButtonDown and/or have our TrackMove method just call the CJ TrackMove method (and then return without executing any of our code).

Note I have no such issues using the Office2007 ribbon theme (blue, black, silver or aqua).

Also on the dialog we insert into the popup, we implement OnCtlColor and set the background for static text objects to be transparent. I don't think CJ is handling static controls with a transparent background set in OnCtlColor appropriately.

So it appears that CJ has problems drawing a popup bar using the Office2013 white ribbon theme. I have examined the INI file but I don't see what setting CJ is using that is affecting my popup control, which isn't even on the ribbon to begin with. I have never noticed any other themes affecting this popup window. Our popup window is not a window on the ribbon. We display it in our viewing area and it hosts dialog boxes used by some commands. In fact, we have support for the window being a layered window and whatever CJ is doing, my calls to Windows to set the layered attributes no longer have an effect when running with Office2013 white. Even if I don't set the attributes or the layered window style, the background is not displayed and my text objects have their display corrupted.

So why does the Office2013 white theme affect my popup window? And more importantly, how can I avoid having that window affected by this display problem?

Why did CodeJock remove that loop from their TrackMove method causing the update issues we see if we don't put the code back and what can I do to fix that problem too without causing skinning to lock us up?

It looks like deadlock. I have one thread doing this:

     ntdll.dll!NtWaitForSingleObject    Unknown
     KernelBase.dll!WaitForSingleObjectEx    Unknown
     nvoglv64.dll!0000000068feaf9a    Unknown
     nvoglv64.dll!0000000068eedccb    Unknown
     nvoglv64.dll!0000000068eef57c    Unknown
     nvoglv64.dll!0000000068feaad9    Unknown
>    ToolkitPro1631vc110x64UD.dll!CXTPSkinManagerApiHook::ThreadProcHook Line 1297    C++
     kernel32.dll!00000000770059ed    Unknown
     ntdll.dll!RtlUserThreadStart    Unknown

Meanwhile the main thread is waiting too:

     user32.dll!ZwUserGetMessage    Unknown
     user32.dll!GetMessageW    Unknown
>    cmdsptd.dll!SEActionHandlePanel::TrackMove Line 1681    C++
     cmdsptd.dll!SEActionHandlePanel::OnLButtonDown Line 2160    C++

SEActionHandlePanel is one of our CXTPPopupControl derived windows that we have that uses the original PeekMessage/GetMessage/DispatchMessage code to avoid the display issues that come about when CJ removed that code from CXTPPopupControl::TrackMove.

Sometimes I can move the window and sometimes not. Sometimes I can move it a bit and have no lockup and then move it again and it locks up. Sometimes after it locks up for a while it will start tracking again. Quite unpredictable. Is this a hooking and threading issue?