When you finish, AppWizard creates a "project," including a set of files that contain the basic elements of an MFC application, implemented as C++ classes:
You won't use this class initially, but its ultimate purpose in MFC is to house the data for a document ¾ usually the unit of data that the user works with between File Open and File Close commands. Most documents are based on disk files, although they need not be.
This is the class you'll use most for this migration guide. A view is a child window embedded in the client area of a frame window. It manages the client area by displaying the data from an associated document. It also takes mouse and keyboard input, which it translates into selection and editing actions. In the simplest terms, the view class is where you put your client-area code. The default view class takes care of a lot of functionality, but you must supply the display code and the input-handling code.
Note For more information about documents and views, see Documents and Views.
In an SDI application, a frame window object frames a view (or sometimes multiple views, as in the case of splitter windows) and routes messages to it. In an MDI application, the application's main frame window contains document frame windows (MDI children), one per open document.
The one and only application object in an MFC application manages application-level functionality. The application class implements common menu commands, including File Open, File New, and File Exit. It also supplies the InitInstance function that you use to initialize your application as a whole. The application creates and communicates with documents via "document template" objects.
What you get in the files created by AppWizard is an application-specific C++ class derived from each of the following MFC base classes: CDocument, CView, CFrameWnd (or CMDIFrameWnd and CMDIChildWnd), and CWinApp. By virtue of C++ inheritance, these classes contain all the behavior of their base classes plus whatever you choose to add to them. The rest of this migration guide concerns what you add and why and where you add it.
Figure 4 shows the objects in a running MFC SDI application and how they communicate.
The parts of this framework that you'll use in the procedure described in this migration guide are quite limited. You'll move most of your code into three functions in your MFC application's view class, derived from CView. That move takes you a long way. Eventually, you can move parts of your message handling code into other functions in other classes (see Phase 2).
Even before you add a line of your own code to the MFC skeleton that AppWizard creates, you can build the project and run the skeleton application. The application lets a user open windows, some of the menus already work, some of them bring up dialog boxes, and the application has any features you selected when you ran the wizard —such as a toolbar, a status bar, an About dialog box with a 3D look, and so on (for SHOWDIB, you omitted some options). You're looking at the tip of the MFC iceberg; MFC — an "application framework" — implements a great deal of standard Windows functionality that you don't have to program yourself.
Try out the skeleton by compiling and running it now. Then you can start filling in the skeleton.