Child Window Not Processing WM_SIZE

[anachronon]

Thanks for checking that out, Freddie. I can think of only one possible reason for my problems with this---the custom menu shell that I developed for this particular program. It is the only thing that is fundamentally different between your code and mine.

Yet, that still makes no sense. The custom menu shell only works on the messages sent to the main window procedure. I don't see how that could be interfering with messages sent to a child window. I am intercepting the main window's WM_NCCALCSIZE, to create a completely blank window (on which I build my menu shell). Could this be interfering with the WM_SIZE messages sent to the child?

[freddie1]

Found this in the MS Docs for WM_SIZE....

Remarks

If the SetScrollPos or MoveWindow function is called for a child window as a result of the WM_SIZE message, the bRedraw or bRepaint parameter should be nonzero to cause the window to be repainted.

Although the width and height of a window are 32-bit values, the lParam parameter contains only the low-order 16 bits of each.

The DefWindowProc function sends the WM_SIZE and WM_MOVE messages when it processes the WM_WINDOWPOSCHANGED message. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc.

Anything like that going on?

[anachronon]

Thanks Freddie. That was the problem! For some reason, I had forgotten to include this key bit of code at the end of my child window procedure:

return DefWindowProc(hImgCh, iMsg, wParam, lParam);

It all works normally now. I don't know where my brain was. It must be this insanely cold weather, and all the stress that goes with it.

[freddie1]

Glad you got it!

Some messages can be tricky. I think WM_CTLCOLORSTATIC is the worst I've ever encountered. I hadn't known that either.