Tab order in tab control with nested dialogs (WS_EX_CONTROLPARENT)

Question

In a Win32 API C++ project, I have a dialog with a tab control (3 tabs) and 3 dialogs that are children of the tab control. I load the main dialog with tab control using DialogBoxParam, and the child dialogs from resources with CreateDialogParam. The main dialog appears with the child dialogs. Clicking the tabs shows/hides the correct child dialog, everything working fine.

After searching around about tab orders I found the WS_EX_CONTROLPARENT style to set on the tab control to get tabbing working into the child dialog windows. This works great, except for one problem: The tab control itself never gets focus, so I can't tab to the tab control to change to a different tab with the keyboard. Keyboard focus goes through the child dialog, to the buttons on the main dialog, then directly back to the child dialog, and never stops on the tab control itself, so I have to click on the tab control to change tabs. It's driving me crazy. Any suggestions?

Update: I managed to work around the problem by forgetting about WS_EX_CONTROLPARENT completely, and making the child dialogs siblings of the tab control. Only side effect seems to be more flashing of controls during a repaint, but would still like an answer, since making the child dialogs children of the tab seems cleaner.

Answer 1

Its not cleaner. The recommended way to create tabbed dialogs is to make the tab pages children of the dialog. The tab control simply controls which of the pages is visible, but is not their parent.

This is especially important when you might try to get XP themeing working on the dialog.

WS_EX_CONTROLPARENT is a style intended to be set on the actual 'tab' dialogs.

I presume you have set WS_TABSTOP on the tab control itself? I imagine that WS_TABSTOP and WS_EX_CONTROLPARENT conflict when simultaneously set as they tell the dialog manager to do two entirely different and conflicting - things when the tab cycle reaches the control.

Lastly, I cannot see any reason at all that flickering should increase because the dialog pages are children of the dialog rather than the tab control.

Answer 2

You can't AFAIK because tabbing cycles through the child controls of a dialog by design. Best you could do is preprocess the tab keydown event and if its after the focus is on the last control in the dialog, focus the tab page and discard the event. Not cleaner than the solution you already have it seems to me.