CODEWITHSUNDEEP
winapiuser-interface
EFanZh
EFanZh

Reputation: 2436

Should a group boxes be its content windows' parent window?

When I create a group box, I intend to use it as a container to contain some other windows. So I think the other windows should be the group box's child windows. But when I use Spy++ to inspect some windows in Windows, I find almost no one does this, even Windows' windows don't do this; the group box and its content windows is in the same level; they share a same parent window.

In Visual C++'s dialog editor, I can't find a way to set one control's parent to another control. (If there is a way, do tell me.) Maybe this is why I can't find a lot group boxes being parent windows because they are in a dialog box which is build in Visual C++'s dialog editor.

I think it is better if a group box is the parent of its content windows because it is more logically correct and if I change the group box's position, the content moves along with it. Is it just too troublesome to do this or is there some other reason not to do this?

Upvotes: 0

Views: 411

Answers (1)

Jonathan Potter
Jonathan Potter

Reputation: 37162

The main reason not to do that is it will break normal dialog keyboard handling (e.g. pressing Tab to move through the controls).

The dialog manager doesn't recurse into arbitrary controls when looking for the next control to give the focus to. It has code to handle child dialogs (those with the DS_CONTROL style set), but controls that are children of other controls will be ignored.

Additionally, messages sent from the child controls like WM_COMMAND won't make it back to your dialog procedure unless you sub-class the group box and forward them manually.

The group box is designed to be placed around other controls - it's transparent and doesn't render over them, nor will it swallow mouse clicks. There's no reason not to have it as a sibling of the controls it surrounds.

Upvotes: 3

Related Questions