MORE INFORMATION
Although WS_OVERLAPPED windows do not typically have
owners, they can have owners. Kyle Marsh's MSDN article "Win32 Window Hierarchy
and Styles," states the following:
Overlapped windows may own other top-level windows or be owned by
other top-level windows or both.
Alternatively, the desktop window can be considered the owner and
parent of a WS_OVERLAPPED-style window. A WS_OVERLAPPED-style window can be
drawn anywhere on the screen and Windows will destroy any existing
WS_OVERLAPPED-style windows when it shuts down.
A window that is
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 has a parent only if it is given one explicitly by means of a call to
the
SetParent function.
The owner of a WS_POPUP-style window is set
according to the
hWndParent parameter that is 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 window.
Note: Modal dialog boxes work a little differently: if
hWndParent is a child window, the owner window is the first nonchild
ancestor that does not have an owner (its top-level ancestor).
A
window that is 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
that is 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 the child window is destroyed together 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 the following
three functions that can be used to find a window's owner or parent:
- GetWindow(hWnd, GW_OWNER)
- GetParent(hWnd)
- GetWindowWord(hWnd, GWW_HWNDPARENT)
The
GetWindow(hWnd, GW_OWNER) function always returns a window's owner. For child windows, this
function call returns NULL. Because the parent of the child window behaves
similar to its owner, Windows does not maintain owner information for child
windows.
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.
The
GetWindowWord(hWnd, GWW_HWNDPARENT) function returns the window's parent, if it has one; otherwise,
it returns the window's owner.
Following are two examples of how
Windows effectively uses different windows for the parent and the owner.
- List boxes in drop-down combo boxes.
- Title windows for iconic multiple document interface (MDI)
child windows.
Because of its size, the list box component of a drop-down
combo box may have 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 also.
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. The MDI client window 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 together
with the MDI child window.