I recently ran into problems with an MFC application that was hosting some Windows Form user control in a modal dialog; the application hanged after it lost focus. The problem was the window received
WM_GETDLGCODE message in an infinite loop making it impossible to handle anything else. After a lot of digging, I found that the cause was the missing
WS_EX_CONTROLPARENT style of the window that hosted the WinForms control. What I want to do is summarize the information about this Window style. The most information I’ve been able to pull came from Raymond Chen’s blog The Old New Thing.
First of all, there are two styles: DS_CONTROL and WS_EX_CONTROLPARENT.
The window itself contains child windows that should take part in dialog box navigation. If this style is specified, the dialog manager resources into children of this window when performing navigation operations such as handling the TAB key, an arrow key, or a keyboard mnemonic.
WS_EX_CONTROLPARENT is an extended window style. It tells the dialog manager that it should treat the children of the window with this flag as direct children of the window’s parent (got that?). Raymond has a simple figure in this blog post. When embedding a dialog inside another, make sure you don’t accidentally create duplicate control IDs.
Creates a dialog box that works well as a child window of another dialog box, much like a page in a property sheet. This style allows the user to tab among the control windows of a child dialog box, use its accelerator keys, and so on.
DS_CONTROL is a style for dialog templates. The dialog manager translates this style into window styles and extended window styles. It removes
WS_SYSMENU (if existing) and adds
Bottom line is, the
WS_EX_CONTROLPARENT style tells function that do control searches (such as GetNextDlgTabItem) that they should treat the dialog marked with the flag as a container of other controls (and iterate them) and not a single, big, control.
References to Similar Problems As My Own