MFC Study Notes (1)

2. MFC Overview

 

1. MFC is a programming framework

    

   The various types of MFC (Microsoft Foundation Class Library) are combined to form an application.ProgramThe purpose of the framework is to allow programmers to build applications in Windows on this basis. This is a simpler method than the SDK. In general, the MFC framework defines the outlines of applications and provides standard implementation methods for user interfaces, all programmers need to do is fill in the specific things of the specific application with the predefined interface. Microsoft Visual C ++ provides tools to complete this task: Appwizard can be used to generate a preliminary framework file (CodeAnd resources); resource editor is used to help intuitively design user interfaces; classwizard is used to help add code to the Framework file; finally, compile, implements the application-specific logic through the class library.

   2. encapsulation

      the MFC class library constitutes the MFC framework. The MFC class library is a C ++ class library. These classes can encapsulate Win32 application programming interfaces, application concepts, Ole features, or ODBC and Dao data access functions, it is described as follows.

      (1) encapsulate the Win32 Application Programming Interface

      use a C ++ object to package a Windows Object. For example, class cwnd is a C ++ window object. It encapsulates windows window (hwnd) and Windows window-related API functions in the member functions of C ++ window object, the latter member variable m_hwnd is the former window handle.

      (2) encapsulation of the application concept

      when using the SDK to write a Windows application, you must always define the Window Process, register the Windows class, create a window, and so on. MFC encapsulates many similar processes to complete these tasks for programmers. In addition, MFC proposes a document-View-centered programming mode. The MFC class library encapsulates support for it. A document is a data object operated by a user. A view is a data operation window through which users process and view data.

      (3) encapsulation of COM/Ole features

      OLE is built on the com model, ole-enabled applications must implement a series of interfaces, which is cumbersome. The OLE classes of MFC encapsulate a large amount of complex work of OLE APIs, which provide more advanced interfaces for implementing Ole.

      (4) encapsulate ODBC functions

      use a small number of C ++ classes that can provide more advanced interfaces with ODBC, it encapsulates a large amount of complex work of ODBC APIs and provides a database programming mode.

   4. inherit

      first, MFC abstracts many common features, design some base classes as the basis for implementing other classes. Among these classes, the most important classes are cobject and c1_target. Cobject is the root class of MFC. The vast majority of MFC classes are derived from it, including csf-target. Cobject implements some important features, including dynamic class information, dynamic creation, Object serialization, support for program debugging, and so on. All classes derived from cobject will have or can have the features of cobject. Cve-target provides a message processing architecture by encapsulating some attributes and methods. In MFC, any class that can process messages is derived from csf-target.

      for each object, MFC has designed a set of classes to encapsulate these objects, each group of classes has a base class, which derives many and more specific classes from the base class. These objects include the following types: Window objects, the base class is cwnd, the application object, the base class is cwinthread, the document object, and the base class is cdocument.

      programmers will, based on their actual needs, assign their own classes from appropriate MFC classes to implement specific functions, achieve your own programming goals.

   6. Virtual functions and dynamic constraints

       

      Based on "C ++", MFC naturally supports Virtual functions and dynamic constraints. However, as a programming framework, there is a problem that must be solved: If dynamic constraints are only supported by virtual functions, the virtual function tables will inevitably become too bloated, consume memory, and be inefficient. For example, when cwnd encapsulates windows window objects, each WINDOWS Message corresponds to a member function, which is inherited by the derived class. If these functions are all designed as virtual functions, the implementation is unrealistic due to the large number of functions. Therefore, MFC establishes a message ing mechanism to solve the dynamic constraints of message processing functions in an efficient and easy-to-use way.

      In this way, through virtual functions and message ing, the MFC class provides a wide range of programming interfaces. While inheriting the basic classes, programmers embed their own virtual functions and message processing functions into the MFC programming framework. The MFC programming framework calls the program code at appropriate times and places. This book will fully show the inside story of MFC calling virtual functions and message processing functions, so that readers can have a clear understanding of the programming interfaces of MFC.

   8. Macro Framework System of MFC

       

   As mentioned above, MFC encapsulates the concept of an application and encapsulates the inheritance, dynamic constraints, and relationships and interactions of classes and classes. The encapsulated result is a set of development templates (or models) for programmers ). Programmers use different templates for different applications and purposes. For example, SDI application templates, MDI application templates, rule DLL application templates, extended DLL application templates, and OLE/ActiveX application templates.

   These templates all adopt the document-centric idea, and each template contains a group of specific classes. The composition of typical MDI applications will be discussed in the next section.

   To support encapsulation of application concepts, MFC must do a lot of internal work. For example, to implement the message ing mechanism, the MFC programming framework must first obtain the message and then process it according to the established method. For example, to support DLL programming and multi-threaded programming, MFC uses special internal processing methods to manage important information, such as module status and thread status. Although these internal processes are transparent to programmers, understanding and understanding the internal mechanism of MFC helps to write flexible and powerful programs.

   In short, MFC encapsulates the functions of underlying functions such as Win32 API, Ole API, and odbc api, and provides interfaces at a higher level to simplify windows programming. In addition, MFC supports direct calls to underlying APIs.

   MFC provides a Windows application development mode. program control is mainly completed by the MFC framework, and most of the functions are completed by MFC, predefined or implemented many events and message processing. The framework can handle events by itself, independent of the programmer's code, or call the programmer's code to process specific events in the application.

   MFC is a C ++ class library. programmers use, inherit, and extend appropriate classes to achieve specific purposes. For example, during inheritance, the application-specific events are handled by the programmer's derived classes, and those that are not interested are processed by the base classes. The foundation for implementing this function is C ++'s support for inheritance, virtual functions, and message ing mechanism implemented by MFC.

2. Structure of the MDI Application

    

   This section describes the composition of a typical MDI application.

   Appwizard is used to generate an MDI project T (Without Ole and other support). Appwizard creates a series of files and forms an application framework. These files are divided into four categories: header files (. h), implementation files (. cpp), resource files (. Rc), module definition files (. Def), and so on.

   1. Object that constitutes the application

       

      Figure 1-1 illustrates the structure of the application, and the arrow shows the flow of information.

      The ctapp, ctdoc, ctview, cmainframe, and cchildframe classes are generated from the cwinapp, cdocument, cview, cmdiframewnd, and cmdichildwnd classes, the five types of instances are application objects, document objects, view objects, main frame window objects, and document border window objects. The main frame window contains the window port, toolbar, and status bar. These classes or objects are explained as follows.

      (1) Applications

      The application class is derived from cwinapp. Framework-based applications must have only one application object, which is responsible for application initialization, running, and termination.

      (2) Border window

      For an SDI application, the border window class is derived from the cframewnd class. The mdiclient of the border window directly contains the window port. For an MDI application, the border window class is derived from the cmdiframewnd class. The mdiclient of the border window directly contains the document border window.

      To support toolbar and status bar, you must add member variables of the ctoolbar and cstatusbar types to the derived border window class, and initialize these two control windows in an oncreate message processing function.

      Border windows are used to manage document border windows, window ports, tool bars, menus, and acceleration keys, and coordinate the half-mode status (such as context help (SHIFT + F1 mode) and print preview ).

      (3) Document border window

      The document border window class is derived from the cmdichildwnd class. The MDI application uses the document border window to include the window port.

      (4) Document

      The document class is derived from the cdocument class to manage data. Data changes and access are implemented through documents. The window interface accesses and updates data through document objects.

      (5) view

      The class is derived from cview or its derived class. Associated with the document, the document serves as an intermediary between the document and the user, that is, the document content is displayed on the screen, and the user input is converted to the document operation.

      (6) Document Template

      Document Template classes generally do not need to be derived. The MDI application uses the multi-Document Template Class cmultidoctemplate; The SDI application uses the single-Document Template Class csingledoctemplate.

      The application manages the creation of the preceding objects (application objects, document objects, main border window objects, document border window objects, and view objects) through the document template object.

   3. Relationship between objects in an application

       

      Here, we use graphs to intuitively represent the inheritance or derivation relationships of the involved MFC classes, as indicated by 1-2.

      The classes shown in Figure 1-2 are derived from the cobject class, and all the classes that process messages are derived from the csf-target class. For multi-document applications, the document template uses cmultidoctemplae. The main frame window is derived from cmdifarmewnd and contains the toolbar, Status Bar, and document frame window. The document Framework Window is derived from cmdichildwnd. The document Framework Window contains the view, which is derived from cview or its derived class.

   5. Create an application file

       

Through the above analysis, we can see the content, definition and implementation class of the MDI framework program generated by Appwizard. Next, we will examine the source code files generated by Appwizard from the perspective of files and what the roles of these files are. Table 1-1 lists the header files generated by Appwizard. Table 1-2 lists the implementation files generated by Appwizard and the inclusion relationships between their original files.

Table 1-1 header file generated by Appwizard

Header file	Purpose
Stdafx. h	Standard afx header file
Resource. h	Various resource IDs are defined.
T. H	# Include "resource. H" Defines the Application Object ctapp derived from cwinapp
Childfrm. h	Defines the document Framework Window object ctchildframe derived from cmdichildwnd
Mainfrm. h	Defines the Framework Window object cmainframe derived from cmdiframewnd
Tdoc. h	Defines the Document Object ctdoc derived from cdocument
Tview. h	Defines the ctview object derived from cview

 

Table 1-2 Implementation files generated by Appwizard

Implementation File	Included header files	Implemented content and functions
Stdafx. cpp	# Include "stdafx. H"	Used to generate pre-compiled type information.
T. cpp	# Include "stdafx. H" # Include "T. H" # Include "mainfrm. H" # Include "childfrm. H" # Include "tdoc. H" # Include "tview. H"	Define the implementation of the ctapp and the global variable theapp of the ctapp type.
Childfrm. cpp	# Inlcude "stdafx. H" # Include "T. H" # Include "childfrm. h"	Cchildframe
Childfrm. cpp	# Inlcude "stdafx. H" # Include "T. H" # Include "childfrm. H"	Implemented the class cmainframe
Tdoc. cpp	# Include "stdafx. H" # Include "T. H" # Include "tdoc. H"	Implemented class ctdoc
Tview. cpp	# Include "stdafx. H" # Include "T. H" # Include "tdoc. H" # Include "tview. H"	Class ctview

 

We can see from the column in table 1-2:

The implementation of ctapp uses all user-defined objects, including their definitions; the implementation of cview uses ctdoc; the implementation of other objects only involves their own definitions;

Of course, if you add other operations and reference other objects, you must include the definition file of the corresponding class.

Precompiled header files are described as follows:

Header file pre-compilation refers to some of the MFC standard header files used in a project (such as Windows. h. afxwin. h) pre-compilation. Later, this header file will not be compiled and only the pre-compilation results will be used. This will speed up compilation and save time.

The precompiled header file is generated by compiling stdafx. cpp and named after the project name. Because the precompiled header file is suffixed with "PCH", the compilation result file is projectname. PCH.

The compiler uses the pre-compiled header file through a header file stdafx. h. The stdafx. h header file name can be specified in the project compilation settings. The compiler considers that all commands in the # include "stdafx. H "the previous code is pre-compiled, and it skips # include" stdafx. H "command, using projectname. PCH compiles all the code after this command.

Therefore, the first statement of all CPP implementation files is: # include "stdafx. H ".

In addition, every implementation file CPP contains the following statement:

# Ifdef _ debug

# UNDEF this_file

Static char based_code this_file [] = _ file __;

# Endif

This indicates that if a debug version is generated, it indicates the name of the current file. _ File _ is a macro, which is assigned the name of the file being compiled during compiler compilation.