1 Introduction
There are a lot of details in the MFC development process to indicate that it can be used as a model to do actual guidance for future MFC development. This article describes the memory management of the Mode dialog.
1.1 convention
L 5 Song Tie fonts Representation: Specific definition;
l Little No. 5 Arial Font Represents: VC code
L 5 body fonts: Class name, class object
2 text
There is no mode dialog, Modeless Dialog. The reason is called no model, because the Non-Mode dialog allows the user to operate other windows simultaneously, which can provide additional functions as the tool window in the program main window, separating the functions of each dialog. The most common is Windows operating system hierarchy, such as resource manager, my computer, Word, etc. This article describes the next level of window, such as the attribute setting dialog of Word.
Creating the Mode dialog By "three steps" complete: new -> CREATEWINDOW () -> showwindow. There are usually two ways to be destroyed in the Mode dialog, one is to destroy their own memory with Delete this in the oncdestroy () function of the dialog, and the other is to empty the memory with the delete PDLG in the outside. Let's refer to the first method is self-destruction method, called the second method is the external system.
In fact, the use of the dialogs created by the two methods is exactly the same. Their differences are only in memory by anyone responsible for recycling.
Object-oriented C basic memory management ideas is the direct implementation of this idea by subject itself responsible for memory, the constructor and destructive function of the class. The constructor should contain allocation logic of memory in all objects, which contain release logic in all objects in all objects. In this way, regardless of how the complex memory storage structure is included, the external management method is as simple: for static objects, just a simple object declaration, and for dynamic objects, new / delete can be assigned to objects. / Recycle memory.
But the key issue is that the pointer characteristics of C bring problems. The pointer characteristics brings dynamic memory allocation, but it is a double-edged sword, most of the memory leaks are related to this. For the code of static objects, constructors and destructure objects are hardly compiled into executable as part of the executable, the application will definitely execute this code, and the memory is definitely impossible to leak (unless the system is unpredictable). The dynamic object must be responsible for calling Delete to manually destroy. This is the key to the problem. Many careful programmers often feel painful because they have forgotten the memory leakage, or because of multi-modest DELETE. A serious abnormality has caused the program to crash. I was so memorable, and even I saw him, I didn't feel uncomfortable even when I saw him.
If you use the dialog box with self-destruction capabilities to create a mode dialog box, you will also have to face this problem, and the red X dialog box will be wrapped like the devil. The Mode dialog box uses the Domodal () function to create a Windows window. During the Domodal () returned, the MFC frame will send an NC_DESTROY message to the window, and the window will perform the oncdestroy () function of the window class after receiving the message. Since this class applies self-destruction methods, DELETE THIS will be called, that is, the memory of the window object has been cleared (since). This is the destructor of the first call class. Then, because the mode dialog is a static object, the application will perform a destructive function again ... Don't tell me, do you know what? The dialog box draws red X! Horror! "Oh! In fact, I applied self-destruction method for it, of course, in order to use a modeless dialog box!". Maybe you will argue this for your self-destruction dialog.
Oh, let me do this for your sentence: Self-destroying dialog box class can only create a modeless dialog. Yes, for your own procedure, for the current program, there is of course so much don't need to consider it.
However, more important reason is that self-destruction is used. Once the program needs this dialog, you will have to directly modify the code of the dialog box class. If you use this class as a binary component to others, this class will be useless for those who need to use the Mode dialog.
If you use export damages, then these problems don't exist. You need to remember that you must manually call DELETE PDLG. This although there are many DELETE PDLG calls, you can know where it creates it, and then it is destroyed, all of which is firmly grasped. Moreover, you can create a mode and non-Mode dialog box based on different needs, this in fact improving the flexibility and scalability of the program.
3 conclusions
Self-destruction dialog box limits the creation mode of the dialog, which reduces the flexibility and scalability of the program. There is no such limit for the export damn dialog box. The writing style of modern programs is more emphasis on program scales and flexibility, so I suggest that the export system is used in the program.
