MFC destroywindow[Goto]

consider a single window case:

Assume that you created a Window object PWND by using new, and then Pwnd->create. The call order of the window is destroyed:

1. Call Pwnd->destroywindow manually ();

2. DestroyWindow will send Wm_destroy;

3. Wm_destroy corresponding message processing function is OnDestroy ();

4. DestroyWindow will send Wm_ncdestroy;

5. Wm_ncdestroy corresponding message processing function is OnNcDestroy;

6. OnNcDestroy will finally call PostNcDestroy;

7. PostNcDestroy is often overloaded by the user to provide free memory operations. For example, you can use delete this;

In this way, the Window object and the Window object itself are freed.

If a child window is included:

If you have a child window, when you call the parent window's DestroyWindow, it sends the Wm_destroy and Wm_ncdestroy messages to the child window.

The specific invocation sequence refers to the following example.

　　 DestroyWindowtheDeleteImpact of:

It should be said that the former has no effect on the latter. But often the DestroyWindow indirectly causes the execution of the PostNcDestroy in the Delete window object pointer, which is deletethis.

CView: The only action in:P Ostncdestroy is Deletethis;cframewnd: So is the:P ostncdestory. The default CWnd::P Ostncdestroy is an empty operation, nor is it overloaded in CDialog, which is also empty.

　　 DeletetheDestroyImpact of:

Delete causes a destructor. CWnd's destructor has a call to DestroyWindow, but it must be guaranteed:

M_hwnd! = NULL &&

This! = (cwnd*) &wndtop&&this! = (cwnd*) &wndBottom&&

This! = (cwnd*) &wndtopmost&&this! = (cwnd*) &wndnotopmost.

CDialog's destructor also has a call to DestroyWindow, but the conditions are relatively loose, and only m_hwnd!=null is required. Additionally CDialog: The DestroyWindow is also called by the:D Omodal.

DestroyWindow is called in the OnClose of CFrameWnd, but DestroyWindow is not invoked in its destruction.

The CView of the DestroyWindow is not called by the destructor.

　　 aSDIprocedures for the destruction process

There are CMainFrame class, CMyView class. And CMyView has two sub-Windows CMyDlg and Cmywnd instances.

Click the Exit button and CMainFrame will receive the WM_CLOSE message. CframeWnd (the parent class of CMainFrame) invokes CWnd indirectly::D Estroywindow; it first sends Wm_destory and WM_NCDESTROY messages to CMyView and throws the corresponding handler functions Then send the wm_destory and Wm_ncdestroy messages to the CMyDlg and throw the corresponding handler functions, then send wm_destory and Wm_ncdestroy messages to Cmywnd and throw the corresponding handler functions.

The specific order of execution is:

1. Call CMainFrame::D Estroywindow

2. Cframewnd::ondestroy

3. Cmyview::ondestroy

4. Cmywnd::ondestroy

5. Cmydlg::ondestroy

6. Cmywnd::P Ostncdestroy

7. Destruction of Cmywnd

8. Cmydlg::ondestroy

9. Destruction of CMyDlg

CMyView::P Ostncdestroy

The destruction of CMyView

The destruction of CMainFrame

CMainFrame::D Estroywindow exit

The above scenario assumes that we have added deletethis to the PostNcDestroy of Cmywnd and CMyDlg. If not added, then 7, 10 will not be executed.

Because CView: DeleteThis is called in the:P Ostncdestroy, the CMyView destructor is then performed. Because CFrameWnd: DeleteThis is called in the:P Ostncdestroy, the CMainFrame destructor is executed last.

If your own CMyDlg and Cmywnd have deletethis in PostNcDestroy, the two will be refactored. Otherwise, the memory leaks. Of course, delete can also be placed in the cmyview of the destruction to do, just not enough oo.

Summarize

There are two ways to destroy window objects corresponding to Windows and to release window object pointers. One is through DestroyWindow. This is a good approach, because eventually MFC will automatically wm_close cause Cframwnd::D Estroywindow is called, and then the handle of all child windows is released at once. What the user needs to do is release the heap window object pointer in PostNcDestroy. However, because some objects are requested in the stack, deletethis can be faulted. This ensures that the windows that you create when you write the program use heap requests as much as possible.

The other is delete. Delete a Window object pointer some window classes (such as Cwnd,cdialog) call DestroyWindow indirectly, and some window classes (such as cview,cframewn) do not call DestroyWindow. So be careful.

The two are called each other and are cumbersome.

　　 a Good article: (Shiyang)

An MFC Window object consists of two aspects: the Window object encapsulated by the window, the hwnd stored in the M_hwnd Member (window handle), and the Window object itself being a C + + object. To delete an MFC window object, you should first delete the Window object that encapsulates the window, and then delete the Window object itself.

The most straightforward way to delete a window is to call CWnd::D Estroywindow or::D Estroywindow, which encapsulates the latter's functionality. The former will not only invoke the latter, but also invalidate the HWND of the member M_hwnd (NULL). If DestroyWindow deletes a parent window or owner window, the function automatically deletes all child windows or owners before deleting the parent window or owner. In general, you do not have to call DestroyWindow directly in your program to delete a window, because MFC automatically calls DestroyWindow to delete the window. For example, when a user exits an application, a WM_CLOSE message is generated that causes MFC to automatically invoke CWnd::D Estroywindow to delete the main frame window, and when the user presses the OK or Cancel button within the dialog box, MFC automatically calls CWnd::D Estroywindow to delete the dialog box and its controls.

The deletion of the Window object itself is divided into two situations, depending on how the object is created. In MFC programming, a large number of window objects are used, some window objects are embedded in other objects as variables or created on the stack as local variables, and some are created in the heap with the new operator. For a window object created as a variable, the programmer does not have to worry about its deletion, because the object's lifetime is always limited, and if the object is a member variable of an object, it disappears as the parent object disappears, and if the object is a local variable, it is cleared when the function returns.

For a window object that is dynamically created in the heap, its lifetime is arbitrarily long. When beginners learn C + + programming, the use of the new operator is often less practical, because creating objects in the heap with new does not forget to delete objects with delete. As readers learn about MFC's routines, they may have questions about why some programs create a Window object with new, but do not explicitly delete it with delete? The answer to this question is that some MFC window objects have the ability to purge automatically.

As mentioned in the previous non-modal dialog box, when you call CWnd::D Estroywindow or::D estroywindow Delete A window, the PostNcDestroy member function of the deleted window is called. The default PostNcDestroy does nothing, but some MFC window classes overwrite the function and call DeleteThis in the new version of PostNcDestroy to delete the object, which has the function of automatic cleanup. Such window objects are usually created in the heap with the new operator, but programmers do not have to worry about deleting them with the delete operator, as the corresponding window object will be deleted immediately after the DestroyWindow delete window is called.

window classes that do not have the automatic cleanup feature are shown below. These window objects are usually created as variables without the ability to automatically clear them.

All standard Windows control classes.

1. Child window objects derived directly from the CWnd class (such as user-customized controls).

2. Splitting the window class CSplitterWnd.

3. The default control bar class (including toolbars, status bars, and dialog bars).

4. Modal dialog box class.

window classes with automatic cleanup are typically created in the heap, as shown below.

1. Main frame window class (derived directly or indirectly from the CFrameWnd class).

2. View class (derived directly or indirectly from the CView Class).

When designing your own derived window class, readers can decide whether or not to design a window class to be automatically cleared, depending on how the Window object is created. For example, for a non-modal dialog box, its object is created in the heap, so it should have automatic cleanup capability.

In summary, for MFC window classes and their derived classes, it is generally not necessary to explicitly delete a Window object in a program. That is, you do not have to call DestroyWindow to delete Window object encapsulation windows, and you do not have to explicitly delete the Window object itself with the delete operator. As long as the window object that is not automatically cleared is created as a variable, the window object that is automatically cleared is created in the heap, and MFC's operating mechanism ensures that the window object is completely deleted.

　　If you need to delete the Window object manually, you should first call the appropriate function (such as CWnd::D Estroywindow) to delete the window and then delete the Window object. For a window object created as a variable, the deletion of the Window object is automatically done by the framework. For a window object that is dynamically created in the heap that is not automatically purged, you must explicitly call delete after the window is deleted to delete the object (typically in the owner or parent window's destructor). For window objects with automatic cleanup, you can simply call CWnd::D Estroywindow to delete window and Window objects. Note that for window objects created in the heap, do not delete the Window object with the delete operator if the window is not closed.