MFC child windows and parent windows

MFC child window and Parent window (Setparent,setowner)Category: VC + + Learning 2012-08-17 16:55 553 people read comments (0) favorite reports Mfclist Data Structure Nullwindowshierarchy

Turn from: http://hi.baidu.com/winnyang/blog/item/c4fdcd3698b33ad1a2cc2b79.html I. Concepts and differences

In Windows systems, each window object should have a data structure that forms a list of lists. The window manager of the system uses this list to retrieve window information and manage each window. In this data structure, there are four data to build the list, that is, child, sibling, parent, owner four domains.
So we can see that there are two kinds of relationships between windows: owner-owned relationship and parent-child relationship. The former is called the owning/being possessed relationship, the latter is called the parent/child relationship. In this text, I put the owner window called the owners window. In other words, a window may be owned by a different window (owner) While there is a parent window, or it can have its own child window. In the CWnd Class of MFC, the owner window is saved in the M_hwndowner member variable, and the parent window is saved in M_hparent, but the two values do not necessarily correspond to the values in the Window object's data structure.

The relationship between the Windows determines the external performance of the window. such as display, destruction and so on.

If the owner domain of a window data is not NULL, then it establishes a owner-owned relationship with the window, and the owning relationship determines:
(1) The owned window is always displayed in front of the window that owns it;
(2) When the owner window is minimized, the window it owns will be hidden;
(3) When the owner window is destroyed, the window it owns will be destroyed.
Note that hiding the owner window does not affect the visible state of the window it owns. For example: If window A has window B and Window B has window C, window B is hidden when window A is minimized, but window C is still visible.

If the parent field of a window is not NULL, then it establishes a parent-child relationship with the window. The father and son decided:
(1) The display position of the window above the screen. The parent window provides the coordinate system used to locate the child window, and a child window can only be displayed in the client area of its parent window, and the outside portion will be trimmed. This reduction rule determines that if the parent window is not visible, the child window is definitely not visible. If the parent window is moved outside the screen, the child window is the same.
(2) When the parent window is hidden, all its child windows are also hidden.
(3) When the parent window is destroyed, the child window that it owns will be destroyed.
Attention! The minimized parent window does not affect the visible state of the child window, and the child window is minimized with the parent window, but its Ws_visible property does not change.

Why do Windows systems use two relationships? This is for a more flexible management window. For example, the drop-down list box (combobox) of a combo box can go beyond the client area of the parent window of the combo box, so it is useful to display, so the system creates the list box as a subwindow of the console window (the desktop Windows). Its parent window hwndparent is null so that the list box's display area is limited to the entire screen, but the list box owner is the first non-subwindow ancestor of the combo box (such as a dialog box), and the list box is automatically destroyed when its owner window is destroyed.

In addition, the delivery of messages between windows is also related to window relationships, and usually a window sends its own notification message to its parent window, but not all, for example, CToolBar sends a notification message to its owner window instead of the parent window. This allows the toolbar to be used as a subwindow for a window (such as an OLE container program window) and to send messages to another window (such as the in-place frame window). Microsoft does not explicitly indicate to whom a certain type of window is sent, whether it is a parent window or an owner window. Also, in the case of field (in-place) editing, when a server window is active or invalid, the window's own subwindow is automatically hidden or displayed, which is also achieved by calling the SetOwner function directly.

Ii. description and limitations of window types

(1) Console Windows (Desktop window). This is the first window created by the system. You can think of it as the owner and parent window of all ws_overlapped type Windows. In his article "Win32 window Hierarchy and Styles," Kyle Marsh points out that when the system initializes, it first creates a console window that covers the entire screen. All other windows are displayed on this console window. Window Manager The window that is used in the list is the first one in this console. The next layer of the window is called the top-level window (top-level), and the top-level window refers to all non-child, no-parent windows, or windows that are desktop windows, and they do not have a ws_child property.

(2) ws_overlapped type of window can be displayed anywhere on the screen. Their owner window is the console.

windows of the Overlapped type belong to the top-level window, typically as the main window of the application. This type of window is created with a title bar and a border, regardless of whether the ws_caption or Ws_border attribute is given. The overlapped window can have other top-level windows or be owned by other top-level windows. All overlapped windows have ws_clipsiblings properties. The system can automatically set the size and initial position of the overlapped window.

When the system shuts down, it will destroy all windows of the overlapped type.

(3) Ws_popup types of Windows can be displayed anywhere on the screen, they generally do not have a parent window, but if SetParent is explicitly called, such windows can also have a parent window.

The owner of a window of type ws_popup is given by setting the hWndParent parameter in the CreateWindow function, if hwndparent is not a child window, the window becomes the owner of this new pop-up window, otherwise, The system is looked up from the parent window of the hwndparent until the first non-child window is found, as the owner of the popup window. When the owner window is destroyed, the system automatically destroys the popup window.

Pop-up types of Windows also belong to the top-level window, and the main difference between it and the overlapped window is that pop-up windows do not need to have a title bar, or have a border. Pop-up can have other top-level windows or be owned. All pop-up windows also have the Ws_clipsiblings property.

(4) The owner window can only be a window of the overlapped or pop-up type, and the child window cannot be the owner window, that is, the child window cannot have other windows.

Overlapped or pop-up types of Windows can also be owned while owning other windows.

When you use CreateWindowEx to create a window of type ws_overlapped or ws_popup, you can give a handle to its owner window in the hwndparent parameter. If hWndParent gives a child-type window handle, the system automatically assigns ownership of the newly created window to the top-level parent window of that subwindow. In this case, the parameter hwndparent is saved in the parent domain of the new window, and its owner window handle is saved in the owner domain.

(5) By default, dialog boxes and message boxes belong to the owned window, unless the Ws_child attribute is explicitly given when they are created (such as when a dialog box is embedded in dialogs)
Otherwise, the system is responsible for assigning them the owner window. It is important to note that once you create a window of type owned, you can no longer change all of its relationships, because WIN32 does not provide a way to change the window owner.

And in Win32, due to the existence of multiple threads, it is important to ensure that the parent-child window or owner/owned window belongs to a thread.

(6) For a window of type ws_child, its parent window is its owner window. The parent window of a child window is also specified in the CreateWindow function with the hwndparent parameter. Child windows can only be displayed in the client area of the parent window and destroyed with the parent window.
The child window must have a parent window, which is the main difference between it and the overlapped and pop-up windows. The parent window can be a top-level window, or it can be a different child window.

Iii. description of several related functions

(1) Get/Set owner window

The Win32 API provides a function GetWindow function (Gw_owner flag) to get the owner window handle of a window.
GetWindow (hWnd, Gw_owner) always returns the owner of the window (owner). For child windows, the function returns NULL because their parent window is equivalent to the owner (note that is "equivalent"). Because the Windows system does not maintain owner information for child windows.

In MFC, the owner window pointer is obtained by using the following function:
_afxwin_inline cwnd* Cwnd::getowner () const
{return M_hwndowner! = NULL? Cwnd::fromhandle (M_hwndowner): GetParent (); }
From the above code we can see that it returns the value and GetWindow returns the difference, if the current window does not have owner, then will return its parent window pointer.

However, Windows does not provide a way to change the window owner. MFC provides a way to change the owner:
_afxwin_inline void Cwnd::setowner (cwnd* pownerwnd)
{M_hwndowner = Pownerwnd! = NULL? pownerwnd->m_hwnd:null;}

In addition, MFC also provides Cwnd::getsafeowner (cwnd* pparent, hwnd* pwndtop), a function that can be used to get the parameter pparent the first non-child property of the parent window pointer. If this parameter is NULL, it returns the main window of the current thread (obtained by AfxGetMainWnd). The framework often uses this function to find the owner window of a dialog box or property page.

(2) Get/Set Parent window

The WIN32 API gives the functions GetParent and setparent. MFC also completely encapsulates these two functions:

_afxwin_inline cwnd* cwnd::setparent (cwnd* pwndnewparent)
{ASSERT (:: IsWindow (M_hwnd)); return Cwnd::fromhandle (:: SetParent (M_hwnd,
Pwndnewparent->getsafehwnd ())); }

_afxwin_inline cwnd* cwnd::getparent () const
{ASSERT (:: IsWindow (M_hwnd)); return Cwnd::fromhandle (:: GetParent (M_hwnd));}

For Setparent,msdn It is stated that the parent-child window must be the same process. However, because the window handle is globally unique and is not part of the same process, it can be called successfully, but the consequences are unknown.
The return value of GetParent is more complex, for a window of type overlapped, it returns 0, for Ws_child type, it returns its parent window, for the Ws_popup type, it returns its owner window, You should use the Getwindowword (gww_hwndparent) function if you want the hwndparent parameter that was passed in when you created it.

(3) Getwindowword (hWnd, Gww_hwndparent) returns the parent window of a window, if not, returns its owner.

(4) As mentioned above, when an owner window is minimized, the system automatically hides the Windows it owns. When the owner window is restored, the system automatically displays the Windows it owns. In both cases, the system sends a (send) Wm_showwindow message to the owning window. At some point, we may need to hide the owned window, but do not want to minimize its owner window, this time, can be implemented through the Showownedpopups function, which sets or removes the Ws_visible property of the window owned by the current window, and then sends Wm_ The ShowWindow Message Update window is displayed.

MFC child windows and parent windows