Resizing display issues.

another side-effekt seems to be: http://forum.codejock.com/forum_posts.asp?TID=22750&PID=73996&title=problems-with-beta3#73996

Astoyan,

I added the call to pOwner->UpdateWindow(). It made no real difference. I also tried modifying the flags to remove the no draw (should have been equivalent) with no change. I tried removing the defer erase flag (drag code) and tried other flags such as SWP_FRAMECHANGED when resizing the owner window. Still no help.

I have implemented similar code for some of our dialogs where we wanted to have a translucent dialog with totally opaque controls. To do that, like your frame shadow solution, I create a layered (LWA_ALPHA) popup window under the dialog that that serves as the "background" of the dialog. The dialog itself is also layered and I use LWA_COLORKEY to make the dialog background transparent. The result is the user sees one window with a translucent background (where I draw various backgrounds, including blurred effects via DwmEnableBlurBehindWindow) but with opaque controls.

To do all that I had to implement the WindowProc of the underlying dialog (set when registering the class)  and in the implementation I had to forward mouse and a few other messages to the dialog window and eat (do nothing) a few IME messages.  When the user resizes, moves, activates, etc. what appears to be a single window, the dialog handles the OnResize and OnMove calls and it drives the sizing of the layered window underneath. In OnMove, I set the window pos of the window underneath using SWP_NOACTIVATE|SWP_NOZORDER. And in OnSize I set the window pos using SWP_NOACTIVATE | SWP_NOZORDER | SWP_NOCOPYBITS | SWP_FRAMECHANGED.
 
Basically, I have the reverse of the shadow implementation - my window drives the one underneath. I didn't use any hooks since I registered the window class providing a window proc in the normal way. Perhaps something like that would work for the shadow implementation.

If I remove SWP_NOCOPYBITS the update is fine. I have also just experimented with no docking panes at all. No documents opened so just a frame and its ribbon. The frame has a background (MDI) window that hosts the web browser control. Resizing shows the same problem.

While I was resizing, I happened to lockup again. This happens, albeit rarely. But this time it was worse. As I moved off the monitor my app was on the cursor didn't change (mouse up at that point). And I could not activate the debugger or any app on any of my monitors. I finally did control-alt-delete and when I got the Windows swtich/logout/etc. page, I hit escape. That returned me to my desktop and I could activate other apps. The resize cursor is gone but my app window is now occluded by the shadow layer window. If I move the cursor over it, the resize (lower left angled arrow) shows up but the app isn't responding. Task manager show the app is maxed out cpu-wise on the core. When I break into the process (I am running from the debugger), I see I am in the html tooltip code calling AfxPumpMessage() loop. The browser control is not reaching the ready state (state is "loading"). So I set a break in the XTPFrameshadowManager::CFrameShadowHook::OnHookMessage. When I step over the AfxPumpMessage() call, I break there.

I see that hook is called from CXTPHookManager:HookWndProc. There is only one hook, the shadow hook. I see only two messages coming into CXTPFrameShadowManager::OnHookMessage - 0x229 (WM_MDIGETACTIVE) and 0x7f (WM_GETICON).

Stack from AfxPumpMessage() looks like this each time I break:

>    ToolkitPro1700vc120x64UD.dll!CXTPFrameShadowManager::OnHookMessage(tagCWPRETSTRUCT * pc) Line 383    C++
     ToolkitPro1700vc120x64UD.dll!CXTPFrameShadowManager::CFrameShadowHook::OnHookMessage(HWND__ * __formal, unsigned int __formal, unsigned __int64 & __formal, __int64 & lParam, __int64 & __formal) Line 73    C++
     ToolkitPro1700vc120x64UD.dll!CXTPHookManager::CHookSink::OnHookMessage(HWND__ * hWnd, unsigned int nMessage, unsigned __int64 & wParam, __int64 & lParam, __int64 & lResult) Line 298    C++
     ToolkitPro1700vc120x64UD.dll!CXTPHookManager::OnWindowsHookProc(int idHook, int nCode, unsigned __int64 wParam, __int64 lParam) Line 519    C++
     ToolkitPro1700vc120x64UD.dll!CXTPHookManager::OnWH_CALLWNDPROCRET(int nCode, unsigned __int64 wParam, __int64 lParam) Line 499    C++
     user32.dll!DispatchHookW()    Unknown
     user32.dll!fnHkINLPCWPRETSTRUCTW()    Unknown
     user32.dll!__fnOUTDWORDDWORD()    Unknown
     ntdll.dll!KiUserCallbackDispatcherContinue()    Unknown
     user32.dll!ZwUserMessageCall()    Unknown
     user32.dll!SendMessageWorker()    Unknown
     user32.dll!SendMessageW()    Unknown
     mfc120ud.dll!CMDIFrameWnd::MDIGetActive(int * pbMaximized) Line 321    C++
     mfc120ud.dll!CMDIFrameWnd::PreTranslateMessage(tagMSG * pMsg) Line 200    C++
     ToolkitPro1700vc120x64UD.dll!CXTPCommandBarsSiteBase<CMDIFrameWnd>::PreTranslateMessage(tagMSG * pMsg) Line 171    C++
     controld.dll!CCustomFrame::PreTranslateMessage(tagMSG * pMsg) Line 3354    C++
     mfc120ud.dll!CWnd::WalkPreTranslateTree(HWND__ * hWndStop, tagMSG * pMsg) Line 3363    C++
     mfc120ud.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg) Line 233    C++
     mfc120ud.dll!CWinThread::PreTranslateMessage(tagMSG * pMsg) Line 778    C++
     mfc120ud.dll!AfxPreTranslateMessage(tagMSG * pMsg) Line 252    C++
     mfc120ud.dll!AfxInternalPumpMessage() Line 178    C++
     mfc120ud.dll!CWinThread::PumpMessage() Line 900    C++

If I break in AfxInternalPumpMessage, I see the pState->m_msgCur.message can be various messages. I see only two messages being pumped, 0xc08f and 0x433. The first message has the window handle of our app/frame window. Spy shows the "next" window is XTPFrameShadow.

The 0x433 message is for a window that Spy shows is an Afx:0000.... window that is a non-visble window with the child being a "Shell Embedding" and with one child being "Shell DocObject View". That window is owned by our app window and has zero size (seen in Spy). But I can't tell what it is. It might be the web browser control window but that window is created with WS_VISIBLE and a 200X200 size. So I don't really think it is the control.

I did pop a window over the shadow and I got a WM_NCPAINT message trapped for the shadow in OnHookMessage. I see a few other display related messages for other windows (xtpTopbar is one) and then things settle down to the messages I already mentioned being the only ones I see.

Did a hook get lost?

At this point, the only thing I can do is restart the app.

Ah. I let the docking panes stay this time and I see what happened. As I move the frame from the lower left corner, the lag in display allows the resize cursor to go over one of the controls we have in the status bar. The tooltip code kicked in and I froze up again. Had to control-alt-delete, escape, to get the desktop to respond again. So this lockup is the same one I reported earlier where if I resize the shadow and a browser control is created after I resize, a call to Navigate will never end up with the control signaling the read state. That's the primary reason I have to turn the shadow off.