ID: Q84190
The information in this article applies to:
In the Windows environment, two relationships that can exist between windows are the owner-owned relationship and the parent-child relationship.
The owner-owned relationship determines which other windows are automatically destroyed when a window is destroyed. When window A is destroyed, Windows automatically destroys all of the windows owned by A.
The parent-child relationship determines where a window can be drawn on the screen. A child window (that is, a window with a parent) is confined to its parent window's client area.
This article discusses these relationships and some Windows functions that provide owner and parent information for a given window.
Although WS_OVERLAPPED windows don't typically have owners, they can. Please see Kyle Marsh's MSDN article "Win32 Window Hierarchy and Styles," which says:
Overlapped windows may own other top-level windows or be owned by
other top-level windows or both.
A window created with the WS_POPUP style does not have a parent by default; a WS_POPUP-style window can be drawn anywhere on the screen. A WS_POPUP-style window will have a parent only if it is given one explicitly through a call to the SetParent function.
The owner of a WS_POPUP-style window is set according to the hWndParent parameter specified in the call to CreateWindow that created the pop-up window. If hWndParent specifies a nonchild window, the hWndParent window becomes the owner of the new pop-up window. Otherwise, the first nonchild ancestor of hWndParent becomes the owner of the new pop-up window. When the owner window is destroyed, Windows automatically destroys the pop up. Note that modal dialog boxes work slightly differently. If hWndParent is a child window, then the owner window is the first nonchild ancestor that does not have an owner (its top-level ancestor).
A window created with the WS_CHILD style does not have an explicit owner; it is implicitly owned by its parent. A child window's parent is the window specified as the hWndParent parameter in the call to CreateWindow that created the child. A child window can be drawn only within its parent's client area, and is destroyed along with its parent.
An application can change a window's parent by calling the SetParent function after the window is created. Windows does not provide a method to change a window's owner.
Windows provides three functions that can be used to find a window's owner or parent:
The return value from the GetParent function is more confusing. GetParent returns zero for overlapped windows (windows with neither the WS_CHILD nor the WS_POPUP style). For windows with the WS_CHILD style, GetParent returns the parent window. For windows with the WS_POPUP style, GetParent returns the owner window.
GetWindowWord(hWnd, GWW_HWNDPARENT) returns the window's parent, if it has one; otherwise, it returns the window's owner.
Two examples of how Windows uses different windows for the parent and the owner to good effect are the list boxes in drop-down combo boxes and the title windows for iconic MDI (multiple document interface) child windows.
Due to its size, the list box component of a drop-down combo box may need to extend beyond the client area of the combo box's parent window. Windows creates the list box as a child of the desktop window (hWndParent is NULL); therefore, the list box will be clipped only by the size of the screen. The list box is owned by the first nonchild ancestor of the combo box. When that ancestor is destroyed, the list box is automatically destroyed as well.
When an MDI child window is minimized, Windows creates two windows: an icon and the icon title. The parent of the icon title window is set to the MDI client window, which confines the icon title to the MDI client area. The owner of the icon title is set to the MDI child window. Therefore, the icon title is automatically destroyed with the MDI child window.
Additional query words:
Keywords : kbNTOS kbGrpUser kbWinOS kbWndw kbWndwProp
Issue type : kbinfoLast Reviewed: December 18, 1998