Measure the test taker's understanding about the basics of MFC in the workshop.

Four main categories

(1) category cmyapp

Cmyapp is an application.ProgramThe basis for running. This class is derived from the cwinapp class in MFC. In this class, except for constructors of general classes, an important member function is initinstance. We know that multiple instances of the same program can be run in windows, the initinstance function is used to initialize a new instance.

The following describes what the initinstance function does. We have defined a document template object pointer pdoctemplate. Through the new operator, the system dynamically generates this document template object, then, use the adddoctemplate function to add this document template object to the linked list of document templates maintained by the application. The purpose of this document template pdoctemplate is to use the Framework Window, cmainframe, and cmydoc of the program, the Windows cmyview is associated with the application object cmyapp.

The cmyapp class provides interfaces for users to communicate with Windows applications. After an object of this class is generated, the object automatically connects itself to the Windows system, receives messages sent by windows, and submits them to the corresponding objects in the program for processing, this frees programmers from a lot of work and makes it easy to develop C ++ Windows programs.

(2) Class cmainframe

The class cmainframe is derived from cframewnd in MFC, so it is also a framework window. It has been pointed out that cmainframe is the parent class of cmyview, that is, the object of cmyview class is displayed in the client area of the main framework window. In the cmainframe class, the system has inherited Windows messages that process common events in the window from the class cframewnd, such as member functions that change the window size and minimize the window, therefore, programmers do not need to care about the processing of such messages during programming, thus reducing the burden on programmers. Of course, if you really need to rewrite the member functions that process such messages, you need to reload the original member functions.

In the MFC program, we do not need to perform regular operations on the cmainframe class, but more operations on the Windows class to edit and modify the data in the program.

Finally, when an instance of the program is running in an MFC program, the system automatically generates a class cmainframe according to the template object described in the cmyapp class, cmyview, cmydoc object, without the need for programmers to actively create these class objects.

(3) category cmyview and cmydoc

The cmyview class and cmydoc class are introduced together because these two classes are closely related. Documents are generated by document template objects and managed by application objects, users store and manage application data through the window objects associated with documents, the interaction between users and documents is performed through the window objects associated with the documents.

When a new document is generated, the MFC program generates a framework window at the same time, and a window object is generated as a child window of the Framework window in the customer area of the Framework Window, this subwindow visualizes the content in the document. An important function of Windows is to process users' mouse, keyboard, and other operations. By processing window objects, You can process document objects.

One point to note is that Windows applications are divided into two types: Single Document Interface SDI and multi-Document Interface MDI. In the single document interface, the document window is the same as the main framework window. The window objects are displayed in the customer area of the document window. The test program generated earlier uses the single-document interface. In this case, the document window is the main frame window, that is, the object similar to cmainframe.

The document/view structure separates data operations, data display, and user interfaces. This is a "divide and conquer" idea. This idea makes the module division more reasonable and the module independence stronger. It also simplifies data operations, data display, and user interface work. The document is only responsible for data management and does not involve user interfaces. The view is only responsible for interaction between data output and user interfaces, and does not consider how the data of applications is organized, you do not need to change the view even when the data structure in the document changes.Code.

Message ing in the MFC Library

The MFC Library application framework does not use virtual functions to process Windows messages. On the contrary, it maps specific messages to the corresponding member functions in the derived class through some macros. The library application framework does not use virtual functions. This is mainly because the library class contains five window classes, which correspond to the five windows window types, if you use a virtual function to process messages, each window base class must define a virtual function for each of the 140 messages. C ++ requires a 4-byte Transfer Structure for each virtual function, called "vtable", whether or not the virtual function is redefined in the derived class, "vtable" is essential. In this way, for each specific type of window or control, the application requires a 2.8kb table to support the virtual message control function.

For menu command messages and button command messages, designing message control functions cannot define them as virtual functions in the basic window class, because different applications have different menu items and buttons. The message ing System of the MFC Library avoids using large vtable tables and can process command messages of various applications. This system also allows some non-window classes (such as document classes and application classes) to control command messages. This message ing system is different from the "dynamic transfer table" system provided by Borland as an integral part of owl. It does not need c ++ for any extension.

The message control function of the MFC Library requires us to provide function prototype, function body, and entry in message ing. classwizard will help us introduce the message control function into our designed class, if we select a Windows Message ID from the list box, classwizard will automatically generate code with correct parameters and return values.