Deep analysis of MFC document View structure (project practice)

The

Document view structure (Document/view architecture) is the essence of MFC and one of the concrete implementation frameworks for observer patterns, Document/view architecture by separating the data from its representation, Provides a good level of data and performance levels of decoupling. However, while using MFC AppWizard, we can easily get an MFC program framework that supports Document/view architecture, Document/view Architecture itself and the complexity of VC generated a series of code enough to let us dazzled, a moment into the fog can not extricate themselves. Plus we more people do not go through the Windows SDK programming learning and experience directly to the MFC programming learning and development, but also face a bunch of code at a loss.

In the Document/view architecture, Mr. Houtie's "easy to explain MFC" a book does have a very in-depth analysis and research, the network also has a lot of Mr. Houtie on the basis of the writings of further articles appear, but personally feel that there is a little flaw (only representative of K_ Eckel: Too deep, these analysis and research will eventually be located in the Windows SDK window creation process, MFC in the Document/view architecture support for the complex and disorderly macros, etc. for the absence of Windows SDK Programming experience and experience of the learners and MFC is not very familiar with the learner is tantamount to increased annoyance, a very complex problem is more complicated. My point of view is that this process is necessary, but not necessarily for everyone, or for everyone in early learning and the vast majority of project development needs. I have always been to a lot of just learned to drag and drop the thought will be MFC (Mr. Houtie in "Easy to MFC" in a book on this group has a face, here does not wordy) disagree, but I still think that the lightweight learning costs are important, easy to start, Acceptance is a great determinant of a technological success or value. So to provide a lightweight learning process for learning is very necessary, this series of articles to follow such a concept, MFC Document/view architecture to carry out an analysis (can also be called in-depth), as far as possible to the Document/view Architecture's theoretical research (many of Mr. Houtie's books) and actual project development combine to provide a simple but comprehensive example of Document/view architecture project development (mainly the design and development of the interface Framework) for reference.

1 Essential Basics Overview 1.1 MFC Document View Structure program structure

When we use MFC AppWizard to generate an MFC program, select all the default settings (also multiple documents, this article is mainly based on multiple documents, for single The document situation is only mentioned in a simple statement, because the latter is much similar to the former, but the former is more complex and more commonly used. , assuming that your program name is a, you get CMainFrame, CChildFrame, CAboutDlg, Cadoc, Caview, CAApp 6 classes (only one less CChildFrame class in single Document, all the rest). The specific meaning of these classes will be given later, and here is the main component of an MFC Support document view structure program (hereafter called app):

U an app (corresponding class Caapp) can contain multiple document templates (CDocTemplate), but MFC AppWizard (either SDI or MDI) only generates one by default. However, in the actual development of a document template is not enough, you need to manually add (in the following actual project examples to provide examples). This structure is implemented through the CWinApp member variable cdocmanager* M_pdocmanager in MFC, and our Caapp is inherited from the CWinApp class provided by MFC.

The U Cdocmanager class has a pointer list cptrlist m_templatelist to maintain the document templates. These document templates are passed through AddDocTemplate (pdoctemplate) in Caapp::initinstance ().

U CDocTemplate has 3 member variables that hold the CRuntimeClass pointer of document, View, frame, and a member variable M_nidresource that specifies the menu resource used when this document is displayed. These 4 data are specified in the constructor of the CDocTemplate in Caapp::initinstance (). A pointer (m_pdoctemplate) in the document that has a anaphora cdoctemplate.

U a document can have multiple views, maintained by CPtrList M_viewlist of the member variables in document.

U CFrameWnd has a member variable cview* M_pactiveview point to the current active view.

U CView has a member variable cdocument* m_pdocument points to the document associated with that view.

[Note]:①MFC sdi/mdi program defaults to generate a document template, and add this document template to its document template list, because this is the default provided by MFC, so this document template will be inserted into the document template in the first position, And MFC is also through this document template specific location can be determined. By default, this document template is enabled when we click on file (Open)/file (New).

In addition to Mr. Houtie's in-depth analysis, listed in the "Easy to understand MFC", we should (to a large extent) have the following knowledge about MFC Sdi/mdi:

The nature of the U document: Documents are used to hold data and data processing, and a document is opened whenever MFC Sdi/mdi response to file (open)/File (New). A document can have multiple views. The relationship between documents and views can be understood as follows: A document is an object that is viewed by a view.

U view nature: A view is a window in Windows, a visual rectangular area. Views are used to represent the data for a document. However, each view must be attached to a frame (SDI is Mainframe,mdi is Childframe). Of course you can create a view yourself and show it.

The nature of the U-frame: The framework is actually also a Windows window. But on the frame, you can place menus, toolbars, status bars, and so on. The view is placed in the client area of the frame. So the window we see in MFC is actually the result of frame and view interaction.

U in a moment, there is only one active document, frame, and view in the program, that is, the current document, frame, view.