Question

I have the following MFC application UI structure:

Main Frame
- CView derived class
 - CWnd derived class
 --- CMFCTabCtrl derived class
 ---- CDialog derived class

The CMFCTabCtrl can hold in turn the CWnd derived class and so on and so on...

If you think of it as a tree of windows lets define the above to be at depth 0.

The problem occurs when the depth of the tree is 1, meaning:

Main Frame
- CView derived class
 - CWnd derived class
 --- CMFCTabCtrl derived class
 ----- CWnd derived class
 ------- CMFCTabCtrl derived class
 -------- CDialog derived class

I added the following code to my application:

extern HHOOK hHook = nullptr;
LRESULT CALLBACK HookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    return CallNextHookEx(hook, nCode, wParam, lParam);
}
hHook = SetWindowsHookEx(WH_CALLWNDPROC, &HookProc, AfxGetInstanceHandle(), GetCurrentThreadId());

I then ran the application and resized the main frame, I noticed the following:

  1. In the case where the tree depth is 0 the WM_ERASEBKGND message is received in the dialog.
  2. In the case where the tree depth is 1 the WM_ERASEBKGND message is not received in the dialog.

I hope my explanation was clear enough.

It seems odd that setting the hook will effect the behavior in such a dramatic way.

Did any of you encounter this sort of problem before?

Was it helpful?

Solution

I think I found the problem. Each time we resize the next nested window the kernel stack increases until it doesn't have enougth stack to call the wndproc and we stop receiving messages.

More details can be found here: http://blogs.msdn.com/b/alejacma/archive/2008/11/20/controls-won-t-get-resized-once-the-nesting-hierarchy-of-windows-exceeds-a-certain-depth-x64.aspx

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top