Window Owners and Parents

Last reviewed: December 15, 1995
Article ID: Q84190
The information in this article applies to:
  • Microsoft Windows Software Development Kit (SDK) versions 3.1
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT versions 3.5 and 3.51
        - Microsoft Windows 95 version 4.0
    

SUMMARY

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.

MORE INFORMATION

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.

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 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:

  • GetWindow(hWnd, GW_OWNER)
  • GetParent(hWnd)
  • GetWindowWord(hWnd, GWW_HWNDPARENT)

GetWindow(hWnd, GW_OWNER) 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.

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 reference words: 3.00 3.10 3.50 3.51 4.00 95
KBCategory: kbui
KBSubcategory: UsrWndw


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: December 15, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.