Is tab control a parent like group box?

[malibor]

Talking of common controls and talking with my self to determine control relationships, I need help with class design..

We can say that group box is a parent window because it can contain child controls, usually buttons.

those child controls send notification to their parent which is group box, if buttons are not part of group box then group box is empty, therefore group box IS fundamentally a parent window.

What is worth nothing is that group box is in same time also a child window because it's not top level and does not run a message loop.
Therefore group box is both a parent and child.

Tab control seems to be similar but by looking at MS docs, it looks like it's not a parent.

Tab control is a child since it's added to top level window or some other kind of a window, however you cannot add child controls to tab control (at least I think so)
The only thing about Tab control is that is has tabs, depending on which tab is selected a top level window should hide windows and controls from one tab and display those in another tab which is currently selected.

Therefore top level window is responsible to manage child windows rather than tab control.

What is confusing is that you can specify tab control to be parent of some control, ex. you can specify HWND parent to be tab control.

Visually however is looks like tab control is just clickable tabs but no client area onto which to put child controls.

So my question is, is tab control a parent or not, would you specify tab as parent window when creating controls in tabs?
Any suggestions about tab control are welcome.

https://learn.microsoft.com/en-us/windows/win32/controls/tab-control-reference
https://learn.microsoft.com/en-us/windows/win32/msi/groupbox-control

[Peter87]

I can't answer about the specifics, but just want to say that things can generally be a child and a parent at the same time. This is true in real life and often in programming. The fact that something is a child and/or parent is often not very useful information on its own if you don't know what it is a child of or a parent of.

Examples:

I am a child of my mom and dad but I'm not a parent because I've got no children.

In a GUI system a button might be a child of a menu container but it might also have child elements such as text or image components.

In a class hierarchy a child class (subclasses) is a class that inherits from another class. The class that is inherited from would then be the parent class (superclass) of the child class.
Example from the standard library: std::basic_ios<char> is a child class (subclass) of std::ios_base and a parent class (superclass) of std::basic_istream<char>. https://en.cppreference.com/w/cpp/io/basic_istream

[malibor]

Thank you, yes well I mentioned group box because it's perfect example of a control that is both parent and child so this idiom is not strange.

What is difficult for me to conclude is whether tab control's HWND should be specified as parent window in CreateWindow function?

ex. pseudo code

HWND hTabControl = // tab control handle
// Create some buttons in one tab
CreateWindow("BUTTON", hTabControl ...)

Here is hTabControl is specified as parent window.
This is confusing portion, because question is, should tab control be specified as parent window?
Or should we specify top level window to be parent?

According to sample code below, if I get it right, tab control should not be a parent window:
https://learn.microsoft.com/en-us/windows/win32/controls/create-a-tabbed-dialog-box

However there is no error is you do specify it as parent window.
I'm wondering what benefit would there be to specify it as parent, which seems like natural way because tab control should be owning childs in it's client area.

EDIT:

I've just set the tab control HWND as parent window and there is a problem that child windows don't send WM_NOTIFY to tab control but instead to top level window.

[malibor]

I have figured out that tab control is not a "real" parent.

Tab control, for each tab must maintain a new sub window, where each sub window owns controls, that is, controls are attached to those sub windows rather than to tab control directly.
This way controls of a sub window send notifications to sub window.

The tab itself can be parent of those subwindows, simply showing and hiding them as tabs are switched.

if Tab control does not have sub windows then controls directly attached to tab control won't send notifications to tab but rather to parent of the tab.

This approach is in line with code samples from MS docs.

Question that remains open is, why don't child controls directly attached to the tab control send WM_NOTIFY to tab control but instead to the parent of tab control?

[andywestken]

This article might help?

How should I create controls on my dialog box that has a tab control?
https://devblogs.microsoft.com/oldnewthing/20191015-00/?p=102996

Windows controls have to work with dialogs created using resource templates. In this kind of case, the app code generally has no visibility of the assorted control's WindowProcs. Which I suppose is why controls notify their parent window.

You can use windows subclassing and superclassing to alter this behaviour. See following article to see what these terms mean wrt windows vs OOA/D.

About Window Procedures
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-window-procedures

[malibor]

This article from Raymond Chen really confirms what I have been debugging, thank you for sharing this, it's very useful!

All my controls are already subclassed, however subclassed tab control doesn't change this behavior with WM_NOTIFY, which is never sent to tab control.

Thank you a lot for this link, this is now solved.