Dialog box about mode and non-Mode

The dialog box can be created using domodal or creat. Domodal creates a modal dialog box, while the non-Modal Dialog Box created by creat summarizes their differences.

For a modal dialog box, before the dialog box is closed, you cannot work in other places of the same application (for example, the open file dialog box). For a non-modal dialog box, it can work in other places while staying on the screen (such as the find file dialog box)

The dialog of create is generally modalless. If your program itself has only one dialog, it doesn't matter, and the modalless effect cannot be seen. Modalless is to have the opportunity to switch to other windows of the program.

The excerpt below is very basic and comprehensive.

Non-modal dialog box features

Unlike the modal dialog box, the non-modal dialog box does not monopolize user input. After you open the non-modal dialog box, you can still interact with other interfaces.

The design of the non-modal dialog box is similar to that of the modal dialog box. It also includes two parts: the Design dialog box template and the design cdialog class derived class. However, during the creation and deletion of the dialog box, the non-Modal Dialog Box differs from the modal dialog box in the following ways:

• The template of the non-modal dialog box must have the visible style; otherwise, the dialog box is invisible, and the modal dialog box does not need to set the style. The more insurance method is to call cwnd: showwindow (sw_show) to display the dialog box, regardless of whether the dialog box has the visible style.

• The non-Modal Dialog Box objects are dynamically created using the new operator in the heap, instead of being embedded into other objects in the form of member variables or built on the stack in the form of local variables. Generally, a pointer member variable pointing to the dialog box class should be declared in the dialog box owner's window class, through which the dialog box object can be accessed.

• Call the cdialog: Create Function to start the dialog box, instead of cdialog: domodal. This is the key to the modal dialog box. Since the create function does not start a new message loop, the dialog box shares the same message loop with the application, so that the dialog box will not monopolize user input. Create returns the result immediately after the dialog box is displayed, while domodal returns the result only after the dialog box is closed. As we all know, in the MFC program, the lifetime of the window object should be longer than the corresponding window, that is, the corresponding window object cannot be deleted without closing the window on the screen. After the return result of create, you cannot determine whether the dialog box is closed or not, so you cannot determine the lifetime of the dialog box object. Therefore, you have to build the dialog box object in the heap, it cannot be constructed in the form of local variables.

• You must call cwnd: destroywindow instead of cdialog: enddialog to close the non-modal dialog box. Calling cwnd: destroywindow is a common method for directly deleting a window. Because the default cdialog: onok and cdialog: oncancel functions call enddialog, the programmer must write their own onok and oncancel functions and call destroywindow in the function to close the dialog box.

• Because the non-Modal Dialog Box object is built using the new operator, you must use the delete operator to delete the dialog box object after the dialog box is closed. After a window is deleted on the screen, the Framework calls cwnd: postncdestroy, which is a virtual function. The program can delete window objects in this function. The Code is as follows:
  Void cmodelessdialog: postncdestroy
  {
  Delete this; // Delete the object itself
  }
  In this way, after the dialog box is deleted, the dialog box objects are automatically deleted. The owner object does not need to explicitly call Delete to delete the dialog box objects.

• There must be a flag indicating whether the non-modal dialog box is open. The reason for this is that you may choose to open the command again when opening a modal dialog box. The program determines whether to open a new dialog box or simply activate the original Dialog Box Based on the flag. Generally, the pointer to the dialog box object in the owner window can be used as this flag. When the dialog box is closed, a null value is assigned to the pointer to indicate that the dialog box object does not exist.

Tip: In C ++ programming, a common method to determine whether an object in the heap exists is to determine whether the pointer to this object is null. This mechanism requires the programmer to initialize the pointer to the object to a null value, assign the returned address to the pointer when creating the object, and set the pointer to a null value when deleting the object.

Based on the above analysis, we can easily change the login data dialog box in the register program to a non-modal dialog box. The advantage of this is that if you find that an error data exists in the editing view when entering the data, you do not have to close the dialog box and modify it in the editing view.

Automatic Clearing of window objects

An MFC window object contains two elements: one is the window object encapsulation window, that is, the hwnd (window handle) stored in the m_hwnd member ), second, the window object itself is a C ++ object. To delete an MFC window object, delete the window object encapsulated by the window object and then delete the window object itself.

The most direct method to delete a window is to call cwnd: destroywindow or: destroywindow. The former encapsulates the latter's functions. The former not only calls the latter, but also invalidates the hwnd saved by m_hwnd (null ). If destroywindow deletes a parent window or owner window, the function automatically deletes all child window or owner, and then deletes the parent window or owner. In general, you do not need to directly call destroywindow in the program to delete the window, because MFC will automatically call destroywindow to delete the window. For example, when a user exits the application, a wm_close message is generated, which causes the MFC to automatically call cwnd: destroywindow to delete the main framework window, when you press the OK or cancel button in the dialog box, MFC automatically calls cwnd: destroywindow to delete the dialog box and its controls.

The deletion of window objects is divided into two types based on the object creation method. In MFC programming, a large number of window objects are used. Some window objects are embedded in other objects in the form of variables or created on the stack in the form of local variables, some are created in the heap using the new operator. For a window object created as a variable, the programmer does not have to worry about its deletion, because the life cycle of the object is always limited. if the object is a member variable of an object, it disappears as the parent object disappears. if the object is a local variable, it is cleared when the function returns.

The lifetime of a window object dynamically created in the heap is arbitrary. When beginners are learning C ++ programming, they are often not very practical about the use of the new operator. Because the object is created in the heap with the new operator, they cannot forget to delete objects with the delete operation. When learning the MFC routine, the reader may have such a question: why does some programs use new to create a window object without explicitly using Delete to delete it? The answer is that some MFC window objects can be automatically cleared.

As mentioned earlier in the non-modal dialog box, when you call cwnd: destroywindow or: destroywindow to delete a window, the postncdestroy member function of the deleted window will be called. The default postncdestroy does nothing, but some MFC window classes will overwrite the function and call Delete this in the new version of postncdestroy to delete the object, thus providing the automatic clearing function. This type of window objects are usually created in the heap with the new operator, but the programmer does not have to worry about using the delete operator to delete them, because once the destroywindow is called to delete the window, the corresponding window object will be deleted immediately.

The window classes that do not have the automatic clearing function are as follows. These window objects are usually created in the form of variables, without the need to automatically clear the function.

All standard Windows Control classes.

Subwindow objects derived directly from the cwnd class (such as custom controls ).

Split Window class csplitterwnd.

The default control bar class (including the toolbar, Status Bar, and dialog bar ).

Modal Dialog Box class.

The window classes with the automatic clearing function are as follows. These window objects are usually created in the heap.

Main framework window class (derived directly or indirectly from the cframewnd class ).

View class (derived directly or indirectly from the cview class ).

　　　

When designing your own derived window class, you can decide whether to design the window class to be automatically cleared Based on the window object creation method. For example, for a non-modal dialog box, the object is created in the heap, so it should have the automatic clearing function.

To sum up, for the MFC window class and its derived class, you do not need to explicitly Delete the window object in the program. That is to say, you do not need to call destroywindow to delete the window encapsulated by the window object, or use the delete operator explicitly to delete the window object itself. As long as the window objects that are not automatically cleared are created in the form of variables, the window objects that are automatically cleared are created in the heap, the operating mechanism of MFC ensures that window objects are completely deleted.

To manually delete a window object, call the corresponding function (such as cwnd: destroywindow) to delete the window and then delete the window object. window objects created in the form of variables are automatically deleted by the framework. for non-automatically cleared window objects dynamically created in the heap, after the window is deleted, delete is called explicitly to delete objects (usually in the destructor of the owner or parent window ). for window objects with the automatic clearing function, you only need to call cwnd: destroywindow to delete the window objects and window objects. Note: Do not use the delete operator to delete window objects created in the heap before the window is closed.

Tip: In the oncancel function of the non-modal dialog box, you can call cwnd: destroywindow instead of cwnd: showwindow (sw_hide) to hide the dialog box. you do not need to call create when opening the dialog box next time. You only need to 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 future use. when the owner window is closed, destroywindow is called to delete each window. As long as the non-modal dialog box is automatically cleared, the programmer does not have to worry about deleting the dialog box objects.

 

 

The destruction sequence of the non-modal dialog box is as follows:

The order in which messages are processed in the MFC Application

1. afxwndproc () This function is used to receive messages, locate the cwnd object to which the message belongs, and then call afxcallwndproc.

2. afxcallwndproc () This function is used to save messages (the content mainly contains message identifiers and message parameters) for future use,
Then call the windowproc () function.

3. windowproc () this function is responsible for sending messages to the onwndmsg () function. If not processed, call the defwindowproc () function.

4. onwndmsg () This function first sorts messages by byte. For wm_command messages, oncommand () messages are called.
Response Function for wm_notify messages
Call the onnotify () Message response function. Any missed message is a window message. Onwndmsg () function search
To find
The processing function that can process any window message. If the onwndmsg () function cannot find such a processing function
Returns a message to the windowproc () function, which sends the message to the defwindowproc () function.

5. oncommand () This function checks whether this is a control notification (the lparam parameter is not null. If the lparam parameter is null, it indicates
The message is not a control notification). If it is, the oncommand () function tries to map the message to the control that creates the notification;
If it is not a control notification (or if the control rejects the ing message) oncommand (), the on1_msg () function will be called.

6. Based on the class that receives messages, the onreceivmsg () function is potentially used in a process called command routing.
Send 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 transmitted to the view and document class for
Class to find a message processing function

 

The process of creating an MFC application window

1. precreatewindow () this function is an overload function. You can change the creation parameters in this overload function before the window is created.
(You can set the window style and so on)

2. presubclasswindow (), which is also an overload function that allows subclassification of a window.

3. ongetminmaxinfo () this function is a message response function that responds to a wm_getminmaxinfo message and allows you to set the maximum or
Minimum Size

4. onnccreate () this function is also a message response function. It responds to the wm_nccreate message and sends a message to notify the customer zone of the window.
To be created soon

5. onnccalcsize () this function is also a message response function. It responds to the wm_nccalcsize message and allows you to change the size of the window client.

6. oncreate () this function is also a message response function. It responds to the wm_create message and sends a message to indicate that a window has been created.

7. onsize () this function is also a message response function that responds to the wm_size message and sends the message to indicate that the window size has been
Changed

8. The onmove () Message response function responds to the wm_move message. sending this message indicates that the window is moving

9. onchildnotify () this function is a heavy-duty function and is called as part of message ing to notify the parent window that a window has just been
Create

 

 

The order in which the MFC application closes the window (non-modal window)

1. onclose () Message response function. The wm_close message in the response window is sent when the close button is clicked.

2. ondestroy () Message response function, which refers to the wm_destroy message in the response window. When a window is destroyed, this message is sent.

3. onncdestroy () Message response function, which refers to the wm_ncdestroy message in the response window. This message is sent when a window is destroyed.

4. The postncdestroy () overload function is called by cwnd as the final action for processing the onncdestroy () function.

 

 

Order of function calls in the open mode dialog box in the MFC Application

1. domodal () overload function, overload domodal () member function

2. The presubclasswindow () overload function allows users to classify a window first.

3. The oncreate () Message response function responds to the wm_create message and sends this message to indicate that a window has been created.

4. The onsize () Message response function responds to the wm_size message and sends the message to notify the window size of the change.

5. The onmove () Message response function responds to the wm_move message and sends the message to notify the window that it is moving.

6. The onsetfont () Message response function responds to the wm_setfont message and sends the message to allow the font of the control in the dialog box to be changed.

7. The oninitdialog () Message response function responds to the wm_initdialog message and sends this message to allow the control in the initialization dialog box,
Or create a new control.

8. The onshowwindow () Message response function responds to the wm_showwindow message, which is called by the showwindow () function.

9. The onctlcolor () Message response function responds to the wm_ctlcolor message and is sent by the parent window to the changed dialog box or the control above the dialog box
Color

10. The onchildnotify () overload function is sent as the result of the wm_ctlcolor message.

 

 

Order of the close mode dialog box in the MFC Application

1. The onclose () Message response function responds to the wm_close message. When the "close" button is clicked, the function is called.

2. The onkillfocus () Message response function responds to the wm_killfocus message. It is sent when a window is about to lose the keyboard input focus.

3. The ondestroy () Message response function responds to the wm_destroy message. When a window is about to be destroyed, it is sent.

4. The onncdestroy () Message response function responds to the wm_ncdestroy message and is sent after a window is destroyed.

5. The postncdestroy () overload function is called by cwnd as the final action for processing the onncdestroy () function.

 

 

Order of opening the modeless dialog box

1. The presubclasswindow () overload function allows users to subclassify a window first

2. The oncreate () Message response function responds to the wm_create message and sends this message to indicate that a window has been created.

3. The onsize () Message response function responds to the wm_size message and sends the message to notify the window size of the change.

4. The onmove () Message response function responds to the wm_move message and sends the message to notify the window that it is moving.

5. The onsetfont () Message response function responds to the wm_setfont message and sends this message to allow the font of the control in the dialog box to be changed.

All the preceding operations are performed in the given order!