CObject most notably the capability to serialize your custom object. Any custom class you want to develop
that needs to save and load data should be derived, directly or indirectly, from CObject.
2.2.2. The Application Class
Every MFC program begins life as an application object. You derive this application object from MFC's
CWinApp class, which provides initialization, runtime, and ending services for your Windows program. More
specifically, CWinApp registers, creates, and shows an application's main window; sets the application's
message loop running (so that the application can interact with the user and Windows); and deletes the
application when the user is finished. CWinApp also provides some additional services, such as providing
access to the application's command line, handling file activity, processing Windows messages, and detecting
when Windows is idle. Every MFC program instantiates a CWinApp-derived object.
2.2.3. The Window Classes
When you create a basic MFC application, it's up to you to tell MFC the type of main window it should create
for the application. This is where MFC's window classes come in. By forcing your MFC application to create
your custom main window, you can add all the functionality you need to your application. To make this task
easier for you, MFC features several different types of windows like Frame windows, View windows, MDI
windows, Dialog boxes etc..
All of the window classes are derived from the CWnd base class, which supplies the basic functionality required
by any window class. This functionality includes initialization, positioning and sizing, painting, coordinate
mapping, scrolling, message handling, and much more. The CWnd class, however, has only one public data
member, m_hWnd, which is the handle of the window with which the class is associated. Although you can
derive your own window classes directly from CWnd, you're more likely to use one of MFC's specialized
window classes.
2.2.4. Frame Windows
Frame windows, represented by the CFrameWnd class, supply all the functionality of the CWnd class and also
handle document/view matters, the menu bar, control bars, accelerators, and more. The CFrameWnd class
contains only two public data members, m_bAutoMenuEnable and rectDefault, which controls whether
menu items are enabled or disabled automatically and controls the window's starting size and position,
respectively.
In most cases, you'll derive the main window class for an SDI (single-document interface) application from the
CFrameWnd class. Such a frame window usually has a complete set of window controls such as minimize,
maximize, restore, and close buttons and holds the application's menu bar, toolbar, and status bar. However,
MFC is flexible enough that you can create just about any type of frame window that you need from the
CFrameWnd class.
2.2.5. View Windows
To make it easier to handle the data associated with an application's window, MFC offers the document/view
architecture. The CDocument classis responsible for storing a window's data, whereas the CView displays the
data, as well as enables the user to manipulate the data.
The CView class provides all the functionality needed by a generic view window. This includes displaying data
in the frame window's client area and printing data. A document can be associated with more than one view.
Although a document can have more than one view, an individual view must always be associated with only a
single document.
MFC derives many specialized view classes from the general CView class. These include CCtrlView,
CEditView, CListView, CRichEditView, CTreeView, CScrollView, CFormView,
CDaoRecordView, and CRecordView. You can tell by the class names what many of these classes do.
2.2.6. MDI Windows
Most document-oriented Windows applications enable the user to open more than one document simultaneously.
MFC provides the CMDIFrameWnd class to encapsulate the extra functionality needed by Multiple Document
我的内容管理
展开
