This chapter describes how to create MFC applications in both document/view and non-document/view architecture. Document/view architecture provides many benefits to the MFC developer, not the least of which is that it makes developing applications faster and simpler. However, the set of starter files and classes automatically generated for a document/view application can seem overwhelming and difficult to decipher.
The first part of this chapter shows how to create a simple MFC application without documents and views so that you can gain an understanding of the basic underlying structure in an easy way. The second part of this chapter explains the document/view architecture fundamentals, helps you analyze the source code of a document/view application, and shows how to create a document/view application.
After completing this chapter, you will be able to:
® Describe the classes used in a minimal MFC application.
® Write a non-document/view application without using MFC wizards.
® Describe the classes used in a document/view application.
® Explain how objects in a document/view application interact with each other.
® Create a document/view application based on the single document interface (SDI) application using AppWizard.
MFC applications are not bound to any particular structure. While some classes are uniquely designed to work in conjunction with one another, all classes can be combined in many different ways to create the solution you want. For example, some applications are based on document/view architecture, while others are based on non-document/view architecture or are dialog-based. Regardless of the type of application, virtually all MFC applications use the same two base classes: the application class, CWinApp, and the frame window class, CFrameWnd.
This section describes the purpose of the CWinApp and CFrameWnd classes and explains how to use them in an application. This section includes the following topics:
The Application ClassThe application class, CWinApp, represents the application as a whole. CWinApp is the base application class that encapsulates the initialization, running, message mapping, and termination of a Windows-based application. The application class also creates at least one document template object.
An application built on the MFC framework must have one (and only one) object of a class derived from CWinApp. This object is constructed before windows are created, at the same time as other C++ global objects. It is available when Windows calls WinMain, which is supplied by MFC. You must declare the derived CWinApp object at the global level.
To see where CWinApp fits into the object hierarchy, click this icon.
As with any Windows-based program, your MFC application has a WinMain function. In an MFC application, however, you don't write WinMain. It is supplied by the framework and is called when the application starts up.
To view an animation that describes the life cycle of an MFC application, click this icon.
What AppWizard Provides
When you create your startup code for a document/view application, AppWizard declares an application class derived from CWinApp. AppWizard also generates an implementation file that contains the following items:
® A message map for the application class
® An empty class constructor
® A variable that declares the one and only application object
® A standard implementation of your InitInstance member function
The standard implementations and message map supplied are adequate for most purposes, but you can modify them as needed for your application. Usually you will add code to the starter code for InitInstance to provide specific functionality to your application. For more information, see Analyzing a Document/View Application in this chapter.
Overridable Member Functions
The following table lists several key overridable CWinApp member functions and describes what they do.
Member function Purpose
InitInstance Creates the document templates that, in turn, create documents, views, and frame windows. InitInstance is the only member function that you must override.
Run After initialization, called by WinMain to process the message loop. A document/view application spends most of its time in the Run member function.
ExitInstance Called each time a copy of your application terminates, usually as a result of a user's quitting an application.
OnIdle Called by the framework when no Windows messages are being processed. Override OnIdle to perform background tasks.
Overriding InitInstance
When you derive an application class from CWinApp, you must override the InitInstance member function to create your application's main window object. Windows allows multiple "copies" of the same program to run at the same time. Each new instance of your application, including the first, is initialized with the information that you place in the overridden InitInstance function.
In general, every Windows-based application has a main window. For this reason, after completing initialization, the framework checks for a pointer to a valid main window (CWinApp:m_pMainWnd) before continuing. If one does not exist, the application terminates.
When you use AppWizard to build an application, AppWizard overrides the default implementation of InitInstance to construct your main window object and sets the m_pMainWnd data member of CWinApp to point to that window.
The frame window class, CFrameWnd, defines the application's physical workspace on the screen and serves as a container for a view. In a single document interface (SDI) application, only one frame window serves as the application's top-level window and frames the view of the document.
CFrameWnd represents the borders of the primary window and automatically positions and sizes the view window. It also "manages" the application adornments, such as the Maximize, Minimize, Save, and Close buttons, the title bar and the title bar icon, the main application menu, the scroll bars, the status bar, and the toolbar.
The CFrameWnd class provides the functionality of a Windows SDI frame window, along with member functions for managing the window. Through a derived class, CMDIChildWnd, the frame window handles multiple document interface (MDI) windows.
To see an illustration that shows where CFrameWnd fits in the object hierarchy, click this icon.
Key Member Functions
The following table lists two key member functions in the CFrameWnd class and describes what they do.
Member function Description
GetActiveDocument Returns a pointer to the current CDocument. If there is no current document, returns NULL.
The Message Map and Message-Handling Functions
Because the CFrameWnd derived class is indirectly derived from CCmdTarget, the derived class can receive and handle command messages. You can specify what happens when messages are directed to the window by implementing message-map and message-handler member functions in the derived class. The message map associates messages with the specific handler functions that handle the messages. For more information about working with the message map, see Chapter 6: Handling Messages.
No comments:
Post a Comment