Introduction
Creating applications using the MFC document/view architecture can save time, can help you create more structured programs, and can also help alleviate a lot of tedious boilerplate coding that you may otherwise be forced to write. It can, however, force you to structure your applications in a way that doesn't quite fit the problem you are trying to solve (such as games), and it does also mean you are forced to carry the overhead of using the MFC runtime libraries. If you are sure that your user will have the version of MFC already installed, or you don't mind including it in a setup program, and you don't mind an executable that is a touch larger than an equivalent win32/SDK version then MFC can save you a lot of time.
The doc/view architecture that is mentioned a lot in MFC literature simply refers to the practice of separating your appplications data storage and minipulation logic from the data visualisation logic. Basically, you have a CDocument derived class to load, manipulate and store your data, and a CView derived class to display the data. Your document and view classes (you can have multiple document and multiple view classes within a single app) are linked together using internal MFC classes by your main application's (CWinApp derived) class, and physically managed on the screen by a Main Frame (CFrameWnd or CMDIChildWnd derived) class.
In Single Document Interface (SDI) applications, there is one CFrameWnd class and and one view. Each time a document is loaded the view is cleared and redrawn using the information in the new document. The view is essentially reused.
The image below shows a typical SDI application. The main window contains the menu, toolbar, status bar, and the view window. The menus, toolbar, status bar are created and owned by the CFrameWnd class. You can create entire applications without having to touch the frame class at all.
The CView class has, as its display area, the dotted section shown in the image. Everytime that area needs repainting the class' OnDraw method will be called, and the view will be expected to query it's associated document so it knows what to draw.
In Multiple Document Interface (MDI) applications there is one main frame per application (in this case a CMDIFrameWnd, and one CMDIChildWnd derived child frame for each document.
Each time a new document is opened a new CMDIChildWnd is created that lives inside the main applications CMDIFrameWnd window. The main frame window contains and owns the menus, toolbars and status bar, and each CMDIChildWnd window contains a view window. When you switch between different child frames the main frame automatically updates the menu and toolbars to match that associated with the current view inside the child frame.
In Visual Studio .NET there is a third option that creates a new CFrameWnd each time a new document is opened. This option won't be covered here yet.
It's important to note that each view can only be associated with one document and one frame window. A CMDIFrameWnd window contains zero or more CMDIChildWnd windows, and each CFrameWnd or CMDIChildWnd contains one CView window. However, each document can have more than one view associated with it. A typical example is the case of a splitter window that can be split to show two different views of the same document.
Creating an application
Creating an MFC doc/view application is very simple. Fire up the AppWizard (File | New...) and follow along.
First we select the MFC AppWizard.
Choose either MDI or SDI (dialog based have been covered elsewhere) and click Next until you hit step 4.
This step allows you to customise a bunch of stuff including toolbars, menus, status bar and print preview. Check the boxes and you get all this for free! One important step here is the "Advanced" button. This allows you to specify a file extension that your application will open by default - and which the Windows Shell will associate with your application should the user double click on a file of that type.
Here I've simple entered "my" as my file extension. Once the program is compiled and run for the first time, all .my files will have the icon specified by the IDR_MYSDIATYPE resource (the actual resource name will obviously change with the name of your application).
Continue clicking Next and you will come to the final step that allows you to choose the type of view you want. MFC provides a ton of different CView derived types to make life easier, including HTML viewers, scrolling views, views that wrap common controls and a dialog-type Form view.
Once the wizard has finished you have an application that can be compiled and run immediately. It won't do anything useful, but in a way it already does a lot: toolbars, status bars, menu, printing and print preview and file type registration. All that remains is for you to fill in the details of your document (Serialize will load and save documents, OnNewDocument will be called to create a new document), and your view (OnDraw to do the drawing, and OnInitialUpdate for initialising variables when the view is first created).
To customise the menus, icons and toolbars simply use the resource editors provided with Visual Studio. Life doesn't get any easier.
