MFC modal dialog box and non-modal dialog message processing order

dialog boxes are created in two ways: DoModal and creat. Where DoModal creates modal dialogs, and creat creates non-modal dialogs below to summarize their differences.

For modal dialogs, the user will not be able to work elsewhere in the same application (such as the Open File dialog box) until the dialog box is closed, while the non-modal dialog box can be used elsewhere while it remains on the screen (for example, the Find File dialog box)

Create dialog is generally modalless, if your program itself is only a dialog, it does not matter, do not see the effect of modalless. Modalless would have been a chance to switch to the other windows of this program.

Here is a partial excerpt, very basic, very comprehensive

Features of the Non-modal dialog box　

Unlike modal dialogs, non-modal dialogs do not monopolize user input, and users can still interact with other interfaces when the user opens the Non-modal dialog box.

The non-modal dialog is designed to resemble a modal dialog box, and also includes a design dialog template and a derived class that designs the CDialog class. However, during the creation and deletion of a dialog box, the modal dialog box is different from the Mode dialog box:

• The template for the non-modal dialog must have a visible style, otherwise the dialog box will not be visible, and the modal dialog box does not have to be set to that style. The more insured option is to call CWnd::ShowWindow (Sw_show) To display the dialog box, regardless of whether the dialog box has a visible style.

• The non-modal dialog object is created dynamically in the heap with the new operator, rather than being embedded in another object as a member variable or built on the stack as a local variable. You typically declare a pointer member variable in the owner window Class of a dialog box to a dialog class that accesses the dialog box object.

• Start the dialog box by calling the Cdialog::create function instead of CDialog::D Omodal, which is the key to the modal dialog box. Because the CREATE function does not start a new message loop, the dialog box uses the same message loop as the application, so that the dialog box does not monopolize the user's input. Create returns immediately after the dialog box is displayed, and DoModal is returned when the dialog box is closed. As we all know, in the MFC program, the Window object lifetime should be longer than the corresponding window, that is, you can not close the screen window on the case of the corresponding Window object deleted. Because the dialog is not determined to be closed after create returns, it is not possible to determine the lifetime of the dialog object, so you have to build the dialog object in the heap, not in the form of a local variable.

• CWnd must be called::D Estroywindow instead of Cdialog::enddialog to close the Non modal dialog box. Call CWnd::D Estroywindow is a general way to delete a window directly. Because the default Cdialog::onok and Cdialog::oncancel functions call EndDialog, programmers must write their own OnOK and OnCancel functions and call DestroyWindow in the function to close the dialog box.

• Because the non-modal dialog object is built with the new operator, you must delete the dialog object with the Delete operator after the dialog box is closed. After a window is deleted, the framework calls CWnd::P Ostncdestroy, which is a virtual function in which the program can complete the task of deleting a Window object, as follows
  void Cmodelessdialog::P Ostncdestroy
  {
  Delete this; Delete the object itself
  }
  This allows the dialog box object to be automatically deleted when the dialog box on the screen is deleted. The owner object does not have to explicitly call Delete to delete the dialog box object.

• There must be a flag indicating whether the non-modal dialog box is open. The reason for this is that the user may choose to open the command again, in the case of opening a modal dialog box. The program depends on the flag to open a new dialog box, or simply to activate the previously opened dialog box. You can usually use a pointer to a dialog object in the Owner's window as this flag, and when the dialog box is closed, assign a null value to the pointer to indicate that the dialog object no longer exists.

Tip: In C + + programming, a common way to determine whether an object in a heap exists is to determine if a pointer to that object is empty. This mechanism requires the programmer to initialize a pointer to the object to a null value, assign the returned address to the pointer when the object is created, and place the pointer at a null value when the object is deleted.

Based on the above analysis, it is easy to change the Login Data dialog box in the Register program to the Non-modal dialog box. The advantage of this is that if the user finds the wrong data in the edit view when entering data, you can modify it in edit view without closing the dialog box.

　Automatic Cleanup of Window objects　

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 Delete this in the new version of PostNcDestroy to remove the object, which has the ability to purge automatically. 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.

A child window object derived directly from the CWnd class, such as a user-customized control.

Slice the window class CSplitterWnd.

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

Modal dialog box class.

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

The main frame window class (derived directly or indirectly from the CFrameWnd class).

The 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.

Tip: You can not call CWnd in the OnCancel function of the Non-modal dialog box::D Estroywindow, instead of calling CWnd::ShowWindow (Sw_hide) To hide the dialog box. You do not have to call create the next time you open the dialog box, just call CWnd::ShowWindow (sw_show) To display the dialog box. The advantage of this is that the data in the dialog box can be saved for later use. Since the owner window is called when it is closed, DestroyWindow deletes each of the owning windows, so as long as the non-modal dialog is automatically cleared, the programmer does not have to worry about the deletion of the dialog box object.

Here is a bit of information for reference, the sequence of destruction of the non-modal dialog box:

The order in which messages are processed in an MFC application

1.AfxWndProc () This function is responsible for receiving messages, finding the CWnd object to which the message belongs, and then calling Afxcallwndproc

2.AfxCallWndProc () This function is responsible for saving the message (the content is primarily the message identifier and message parameters) for later use by the application.
Then call the WindowProc () function

3.WindowProc () This function is responsible for sending the message to the Onwndmsg () function, and if it is not processed, call the DefWindowProc () function

4.ONWNDMSG () The function's function first sorts the messages by byte, and for WM_COMMAND messages, calls the OnCommand () message
Response function, for WM_NOTIFY messages
Call the OnNotify () message response function. Any missed messages will be a window message. Onwndmsg () function search
The message image of the cable class to find a
A handler function that can handle any window message. If the onwndmsg () function cannot find such a handler function, then
Returns the message to the WindowProc () function, by which it sends the message to the DefWindowProc () function

5.OnCommand () This function looks at whether this is a control notification (the LPARAM parameter is not NULL and if the lparam parameter is empty, the description
The message is not a control notification), and if it is, the OnCommand () function attempts to map the message to the control that manufactures the notification;
If he is not a control notification (or if the control rejects the mapped message) OnCommand () will call the OnCmdMsg () function

6.ONCMDMSG () Depending on the class that receives the message, the ONCMDMSG () function will potentially be in a process called command Routing
Pass command messages and control notifications.
For example, if the class that owns the window is a framework class, the command and notification messages are also passed to the view and document classes, and the
Class looks for a message handler function




Procedures for creating Windows for MFC applications

1.PreCreateWindow () This function is an overloaded function that can change the creation parameters in the overloaded function before the window is created
(You can set the window style, etc.)

2.PreSubclassWindow () This is also an overloaded function that allows you to first subclass a window

3.OnGetMinMaxInfo () This function is a message response function that responds to the WM_GETMINMAXINFO message, allowing the setting of the window's maximum or
Minimum size

4.OnNcCreate () The function is also a message response function that responds to the Wm_nccreate message and sends a message to tell the client area of the window
is about to be created

5.OnNcCalcSize () This function is also a message response function that responds to the wm_nccalcsize message, which is allowed to change the window client area size

6.OnCreate () The function is also a message response function that responds to the WM_CREATE message and sends a message telling a window has been created

7.OnSize () The function is also a message response function that responds to the WM_SIZE message and sends the message to tell the window that the size has been
Changed

The 8.OnMove () message response function, which responds to the Wm_move message, sends this message stating that the window is moving

9.OnChildNotify () The function is an overloaded function, called as part of a message map, telling the parent that the window is about to be told that a window has just been
Create





The order of the MFC application to close the window (non-modal window)

1.OnClose () message response function, Response window Wm_close message, send this message when the Close button is clicked

2.OnDestroy () message response function, Response window Wm_destroy message, when a window will be destroyed, send this message

3.OnNcDestroy () message response function, Response window Wm_ncdestroy message, when a window is destroyed after sending this message

4.PostNcDestroy () overloaded function, called by CWnd as the last action to handle the OnNcDestroy () function






The sequence of function calls in an MFC application that opens a modal dialog box

1.DoModal () overloaded function, overloaded DoModal () member function

2.PreSubclassWindow () overloaded function, which allows a window to be classified first

3.OnCreate () message response function, in response to a WM_CREATE message, sends this message to tell a window that it has been created

4.OnSize () message response function, in response to the WM_SIZE message, sends this message to tell the window that the size of the change

The 5.OnMove () message response function, which responds to the Wm_move message, sends this message to tell the window that it is moving

6.OnSetFont () message response function, which responds to the Wm_setfont message, sends this message to allow changes to the font of the control in the dialog box

The 7.OnInitDialog () message response function, which responds to the WM_INITDIALOG message, sends this message to allow initialization of the control in the dialog box.
or create a new control

The 8.OnShowWindow () message response function, which responds to the Wm_showwindow message, is called by the ShowWindow () function

9.OnCtlColor () message response function, Response Wm_ctlcolor message, sent by Parent window Changed dialog box or dialog box above control
The color

OnChildNotify () overloaded function, sent as a result of the WM_CTLCOLOR message





Order of closing modal dialogs in MFC applications

The 1.OnClose () message response function, which responds to the WM_CLOSE message, is called when the Close button is clicked.

2.OnKillFocus () message response function, Response Wm_killfocus message, when a window is about to lose keyboard input focus before being sent

3.OnDestroy () message response function, in response to a WM_DESTROY message, is sent when a window is about to be destroyed

4.OnNcDestroy () message response function, in response to a WM_NCDESTROY message, is sent when a window is destroyed

5.PostNcDestroy () overloaded function, called by CWnd as the last action to handle the OnNcDestroy () function

Order of open modeless dialog boxes

1.PreSubclassWindow () overloaded function that allows the user to first sub-categorize a window

2.OnCreate () message response function, in response to a WM_CREATE message, sends this message to tell a window that it has been created

3.OnSize () message response function, in response to the WM_SIZE message, sends this message to tell the window that the size of the change

4.OnMove () message response function, in response to a wm_move message, sends this message to tell the window that it is moving

5.OnSetFont () message response function, which responds to the Wm_setfont message, sends this message to allow changes to the font of the control in the dialog box

http://blog.csdn.net/kl222/article/details/1447985

MFC modal dialog box and non-modal dialog message processing order