The Microsoft Foundation Class (MFC) Library and Visual C++ provide an environment that you can use to easily create a wide variety of applications. This chapter discusses the various class types and primary architectures that are used in most applications.
Objectives
After completing this chapter, you will be able to:
® List the major categories of MFC classes, and the primary classes derived from each category.
® Describe the relationship of the foundation class CObject to the other MFC classes.
® Explain the key features CObject contributes to the classes derived from it.
® Define the main base classes used in a typical MFC application.
® Describe the document/view architecture and how this architecture applies to MFC.
® Describe the benefits and costs of document/view, non-document/view, and dialog-based application architectures.
® Describe how MFC maps messages to functions.
The MFC Library is a collection of C++ classes and an application framework designed primarily for creating Microsoft Windows-based applications. This collection of classes extends the C++ language to include most of the basic structural elements used to create Windows programs. The application framework defines the structure of an application and handles many routine tasks for the application.
This section describes the relationship between MFC and Windows technology, and explains some key advantages that MFC and Visual C++ offer developers.
This section includes the following topics:
- MFC and the Win32 API
MFC does not encapsulate, or wrap, the entire API, just the main structural components and components that are commonly used. Because MFC is written in C++, MFC developers can easily use the Win32 API to make native calls to the operating system.
To see an illustration that shows the relationship between MFC, the Windows Base Operating Services, and the Windows Operating System Extensions, click this icon.
MFC version 1.0 was little more than a thin wrapper for the Win32 API. However, each subsequent version of MFC provides significantly more features and functionality. MFC incorporates many names and constructions familiar to developers who have used the Microsoft Windows Software Development Kit (SDK). For example, MFC provides a member function named CWnd::InvalidateRect that corresponds to the Win32 function InvalidateRec.
Wrapper Classes for Operating System Extensions
MFC encapsulates important Microsoft Windows operating system extensions, including COM, ActiveX, ODBC, and Windows Internet APIs. The encapsulation is not complete. However, combining MFC and native API usage is usually simple.
Visual C++ provides a productive visual development environment that gives you the tools you need to create a wide variety of applications, from client/server solutions to high-performance multimedia applications.
Visual C++ supports the latest in Windows operating system-based technology, including the Windows 95 operating system. Visual C++ offers full support for the common controls in the Windows 95 and Windows NT operating systems, as well as support for the Windows 95 Explorer shell. Most of the new Windows 95-based common controls are fully supported by Visual C++, and you can access them through MFC and the Win32 API.
Some other features that make Visual C++ an excellent choice for developing solutions are:
® Code reusability.
® Application wizards for MFC applications, DLLs, ActiveX controls, Active Template Library (ATL) projects, ATL Component Object Model (COM) objects, and ISAPI extensions.
® The integrated development environment of Developer Studio.
® Components and Controls Gallery, a place to store and access reusable components and controls.
® Support for the MFC Library.
® Portability and cross-platform support.
® Availability in Chinese, English, German, French, Italian, Korean, Japanese, and Spanish.
® Support for the latest C++ features.
The Microsoft Foundation Class (MFC) Library enables you to build on the work of expert Windows developers. MFC shortens development time, makes code more portable, provides support without reducing programming freedom and flexibility, and provides easy access to hard-to-program user-interface elements and technologies such as ActiveX, OLE, and Internet programming. Furthermore, MFC simplifies database programming through data access objects (DAO) and Open Database Connectivity (ODBC), and simplifies network programming through Windows Sockets. MFC makes it easy to program such features as property sheets (tab dialog boxes), print preview, and floating, customizable toolbars.
By using MFC, you can add many features to your applications in an easy, object-oriented way. In MFC version 3.0, you could add ToolTips to your application by adding only three lines of code. With MFC 4.0, a similar amount of code enables ActiveX controls in your application. Now with MFC version 4.2, Visual C++ 5.0, the Gallery, and the wizards, you can add Active Template Library (ATL) components, Internet classes, and synchronization for multithreaded programs.
MFC offers the experienced C++ developer many advantages when developing full-featured Windows applications, front-end database applications, ActiveX controls and components, and Internet applications, such as:
® An application framework on which you can build a Windows application
® Compatibility with previous MFC versions and the new C++ classes
® The largest base of reusable C++ source code in the industry
® Integration with Visual C++
® Flexible, fast database access methods using DAO or ODBC
® Support for ActiveX and Internet technologies
® Support for popular data-binding technologies
® Support for Windows messaging API
® Support for multithreading
The MFC Class Hierarchy
The first step on the road to becoming an MFC developer is becoming familiar with the classes. This section gives you an overview of the kind of infrastructure MFC provides, including the classes and class hierarchy.MFC provides nearly 250 classes designed to serve a wide range of programming needs. The first step in programming with MFC is to become familiar with these classes and learn how they are related to one another in the MFC hierarchy. Some classes are used directly, while others serve as base classes for the classes that you create.
When learning about the MFC classes, it is helpful to organize them into the following categories, which are the topics included in this section:
® CObject-Derived Classes
® Application Architecture Classes
® User-Interface Classes
® General-Purpose Classes
® ActiveX Classes
® Database Classes
® Internet Classes
® Global Afx Functions
These categories of MFC classes are not mutually exclusive. The majority of MFC classes are derived, either directly or indirectly, from CObject.
- CObject-Derived Classes
CObject Hierarchy
To see an illustration that shows the relationship of CObject to the other classes in the MFC class hierarchy, click this icon.
The classes in MFC that are derived from CObject provide most of the structure and functionality of an MFC application. The following table lists some of the most important classes and describes the tasks they perform.
Category Base class Description
Applications CWinApp Represents the core of the application.
Documents CDocument Contains an application's data set.
Windows CWnd For graphical user interface (GUI) objects that are capable of handling general
Windows messages.
Frames CFrameWnd For an application's primary window frame.
Views CView Displays data and interacts with the document object.
In addition, there are many CObject-derived classes for other aspects of a Win32-based application, such as menus, graphics, file services, and so on.
Support for CObject-Derived Classes
CObject provides three basic types of support to classes that inherit from it, as shown in this table.
Type of support Description
Run-time class information Because it is derived from CRuntimeClass, objects derived from CObject contain information about their origins that is accessible at run time. This run-time type-checking feature gives functions the ability to react based on the type of object that is acted on.
Diagnostic output To aid in the development of an MFC application, CObject provides a number of diagnostic or debug output functions. Overriding these functions provides information about the execution of your program that is especially useful when program behavior is not as expected.Classes Not Derived from CObject
MFC also contains a set of classes that are not derived from CObject. These classes are useful in situations where the overhead associated with CObject and run-time type identification are unnecessary. These classes fall into three general categories, as shown in the following table.
Category Examples
MFC support classes to assist the architecture CArchive, CDumpContext, CRuntimeClass, CFileStatus, CMemoryState
Templatized versions of the collection classes that take a user-defined pointer CTypedPointerArray- Application Architecture Classes
Some of the architectural classes include CWinApp, CDocument, CCmdTarget, and CWinThread. These classes are the first to be instantiated when the application starts, and they have significant responsibility.
The following table describes these four classes in more detail.
Class name Description
CWinApp This class represents the application itself. All MFC applications derive a class from CWinApp.Depending on the type of framework chosen, the application object is responsible for:
® Initializing the application.
® Building the document template structures.
® Providing the message loop with retrieved messages from the message queue and
dispatching these messages to the appropriate location.
® Cleaning up the application on exit.
CDocument This is the base class for documents in applications that use document/view architecture. A document is simply an abstract representation of a program's data.A major architectural task for the developer is to determine how data is to be stored in the document, and how and to what extent the document will provide access to that data.
CCmdTarget This is the foundation class for message map architecture in MFC. The capabilities that a class inherits from CCmdTarget enable it to serve as a target for a special class of messages, known as command messages. These messages are generated when the user chooses a command from a menu.
CWinThread This class encapsulates threading capabilities of the operating system. Member functions enable MFC applications to create and manipulate threads.- User-Interface Classes
To see an illustration that shows the user-interface classes within the MFC object hierarchy, click this icon.
Some of the user-interface classes include CWnd, CView, CGdiObject, and CMenu.
CWnd
CWnd is the base class for all MFC windows, and defines the basic functionality of a window and a window's default response to most messages. CWnd is sometimes used directly to derive classes, but more often, classes are derived from the other built-in classes that are derived from CWnd. The following table shows some of the classes that are derived from CWnd.
Class Description
CControlBar Serves as the base class for toolbars, status bars, and other controls.
CDialog Encapsulates the functionality of dialog boxes.
CButton, CListBox, CScrollBar, and so forth Corresponds to controls such as buttons, list boxes, and scroll bars.
CView
Most applications provide the user with one or more views of the underlying data. For example, Microsoft Excel provides a worksheet view and a graphic view of the same data. The CView class, derived from CWnd, is the base class that provides the visible representation in a document/view application.
CGdiObject
The graphics device interface (GDI) portion of Windows is designed to provide applications with a device-independent and feature-rich set of drawing capabilities. The GDI contains a number of "objects" that are used to display output, such as brushes, pens, and fonts. CGdiObject is a wrapper class that provides MFC applications with the ability to create and use these objects.
CMenu
Menus are one of the main methods by which users interact with applications. An application's menu items not only give the user the ability to invoke an action, but they also provide information to the user about the state of the application and what options are currently available.
The CMenu class provides an object-oriented interface to menus. Through the CMenu class interface, the application can dynamically control its menus at run time.
- General-Purpose Classes
To see an illustration that shows the general-purpose classes within the MFC CObject hierarchy, click this icon.
The following table lists some commonly used general-purposes classes and describes the tasks they perform.
Class Task
CString Managing string variables
CException Exception handling
CByteArray, CIntArray, CStringArray, CStringList, CObList Working with data structures such as arrays and linked lists
CPoint, CSize, CRect, CTime, CTimeSpan Miscellaneous
- ActiveX Classes
® Create ActiveX controls and ActiveX control containers.
® Use Automation to control one program with another.
® Create compound documents, which enable users to create and edit documents containing various types of data, including text, graphics, spreadsheets, and sound. These various data objects can be created by different applications.
® Create OLE objects that can be embedded in compound documents.
® Use drag-and-drop to copy data between applications.
To see an illustration that shows the ActiveX and OLE classes within the MFC object hierarchy, click this icon.
ActiveX classes can be divided into the categories shown in the following table.
Category Common classes
Active Document classes CDocObjectServer, CDocObjectServerItem
ActiveX-related classes COleObjectFactory, COleMessageFilter, COleStreamFile, CRectTracker
Automation classes COleDispatchDriver, COleDispatchException
Container classes COleDocument, COleLinkingDoc, CDocItem, COleClientItem
OLE server classes COleServerDoc
OLE drag-and-drop and data transfer classes COleDropSource, COleDataSource, COleDropTarget,
COleDataObject
OLE common dialog classes COleDialog, COleInsertDialog, COlePasteSpecialDialog, COleLinksDialog, COleChangeIconDialog, COleConvertDialog, COlePropertiesDialog, COleUpdateDialog, COleChangeSourceDialog, COleBusyDialog
- Database Classes
To see an illustration that shows the database classes within the MFC object hierarchy, click this icon.
Note This course does not cover creating database applications. For information about how to create database applications using MFC, see Mastering MFC Development Using Visual C++ 5 listed in the Library.
A CDatabase or CDaoDatabase object represents a connection to a data source through which you can operate on the data source. A data source is a specific instance of data that is hosted by a database.
CRecordset and CDaoRecordset
A CRecordset or CDaoRecordset object represents a set of records selected from a data source. Known as recordsets, CRecordset and CDaoRecordset objects are available in two forms: dynasets and snapshots. A dynaset is a dynamic recordset that stays synchronized with updates by other users. A snapshot is a static recordset that reflects the state of the database at the time the recordset is requested. CDaoRecordset also can directly represent a table in a database.
®Internet Classes
To see an illustration that shows the Internet classes within the MFC object hierarchy, click this icon.
Note This course does not cover creating Internet applications. For information about creating Internet applications using MFC, see Mastering MFC Development Using Visual C++ 5, listed in the Library.
Client-Side ClassesThis table describes MFC Internet classes related to the client-side applications.
Class Description
CHttpConnection Manages an application's connection to an HTTP server.
CFtpConnection Manages an application's FTP connection and provides for member functions that enable you to create applications that explore remote directories, retrieve files, and otherwise manage remote file systems.
CGopherConnection Manages an application's Gopher connection and enables the application to search for and retrieve various types of documents.
CFileFind This class, the base class for CFtpFileFind and CGopherFileFind, supports searching, locating, and returning information about found files. All these classes support wildcard searches.
Server-Side Classes
This table describes MFC Internet classes related to the server-side applications.
Class Description
CHttpServerContext Used by CHttpServer to encapsulate the instance of a single client-side request.
CHttpFilter Use this class to create a DLL to filter incoming and outgoing client data.
CHttpFilterContext Used by CHttpFilter to encapsulate the instance of a single notification for a single client.
CHtmlStream Encapsulates an HTML data buffer to be used by a CHttpServer to respond to the client.
MFC provides some functions that are not members of classes. These are global functions whose names begin with Afx. Class member functions can only be called in the context of the class to which they belong, but Afx functions are available to all classes and functions in an application. The following table lists some commonly used Afx functions and describes the tasks they perform.
Function Description
AfxMessageBox() Displays a Windows message box.
AfxGetApp() Returns a pointer to the project's CWinApp object.
AfxGetAppName() Returns a pointer to a string containing the application name.
AfxGetMainWnd() Returns a pointer to the main frame window.
AfxGetInstanceHandle() Returns a handle (HINSTANCE) to the current instance of the application.
Documents, Views, and the Application Framework
Your work with the framework is based largely on a few major MFC classes and several Visual C++ tools. Some of the classes encapsulate the Win32 API. Other classes encapsulate application objects such as documents, views, and the application itself. Still others encapsulate ActiveX, database, and Internet features.
This section presents an overview of the application framework, the major objects that make up your application and how they are created, and a brief look at how messages are handled in the MFC environment. This section includes the following topics:
- Document/View Architecture
Document/view architecture is important because applications that use documents and views derive the greatest benefit from the application framework. You can write MFC applications without using documents and views; however, to get the most out of the framework and take advantage of advanced MFC features, you must use document/view architecture. For more information about non-document/view architecture, see Writing Applications in Non-Document/View in Chapter 4: Creating MFC Applications.
To see an illustration that shows how a single set of data can be viewed or displayed in more than one way by a document/view application, click this icon.
As shown in the previous illustration, Microsoft Graph is a good example of an application that separates the data from the interface. The user can select a set of values from the data in a spreadsheet view, and then display the same information as a bar chart or a three-dimensional bar chart. If the user changes values or changes the range of data that is selected in the spreadsheet view, the chart view is updated. The application can also present two views of the same type; changes made in one view would also appear in the other.
To see a demonstration that shows how the Microsoft Excel application uses document/view architecture, click this icon.
MFC makes it easy to work with both single document interface (SDI) and multiple document interface (MDI) applications.
SDI applications allow only one document frame window at a time. MDI applications allow multiple document frame windows to be open in the same instance of an application. An MDI application has a window within which the user can open multiple MDI child windows that are themselves frame windows, each containing a separate document. In some applications, the child windows can be of different types, such as chart windows and spreadsheet windows. In that case, the menu bar can change as MDI child windows of different types are activated.
- Objects in an SDI Application
The following table lists the application objects and related classes in an SDI application and describes the major tasks each object performs.
Object Description
View Your view class (derived from CView) is the user's window to the data. The view class specifies how the user sees your document's data and interacts with it.
Frame window Views are displayed inside document frame windows using the CFrameWndclass. In an SDI application, the document frame window is also the main frame window for the application.
Document template A document template orchestrates the creation of documents, views, and frame windows. A particular document-template class (derived from CDocTemplate) creates and manages all open documents of one type. Use class CSingleDocTemplate for SDI applications.Application Your application class (derived from CWinApp) controls all of the objects above and specifies the application's behavior such as initialization and cleanup.
In an SDI application, each document template creates and manages one document. The user views and manipulates a document through a view contained inside a frame window. The application objects cooperatively respond to user actions, bound together by commands and other messages. The following illustration shows the relationship between the document/view objects in a running SDI application.
Although most of the discussion about Visual C++ and MFC functionality assumes use of the document/view architecture, this is not a requirement. The benefits associated with document/view architecture also carry with them potentially significant performance and size costs. In some cases, document/view may not be the right choice for your application.
For example, applications that compress files may need only a dialog box that requests file names and displays a progress bar. A main frame window and a view are not needed; document/view architecture would provide little, if any, benefit in this instance. For another example, consider an application that provides a single database recordset to a simple database browser. The document/view architecture could be used, but it may be more effective for the view (the browser) to hold the recordset directly.
Remember that an MFC application consists of a number of objects that you can combine in many ways to create a program solution. Some possible combinations in a non-document/view application include:
® A CWinApp object and a modal dialog box. In such applications, the dialog box is responsible for storing and displaying data.
® A CWinApp object, a main frame (CFrameWnd) window, and a view. In such applications, the view usually is located where any data is stored and displayed.
Regardless of the combination you choose, the non-document/view application usually begins with the override of the CWinApp::InitInstance function. At this point, the main window, either a dialog box or other window, is created.
- Messages
There are many types of messages; two of the most important are standard Windows messages and command messages. The MFC architecture supports Windows messages through the CWnd class and its derived classes, such as CView and CFrameWnd. MFC supports command messages through any of the classes derived from the CCmdTarget class. A command message originates from a menu item, command button, or accelerator key. In Chapter 6: Handling Messages, you will learn how to handle Windows and command messages in MFC applications.
Message Maps
Before you start writing MFC applications, it is important to understand how MFC maps messages to the functions that will handle the messages. The application framework implements the message map data structure, which provides the link between the message ID and the function that will handle the message. Each entry consists of a message-specific macro. Standard Windows messages all have predefined macros containing an implicit ID and handler name. Command message macros contain an explicit ID and handler name.
Below is an example of a message map for the CMyView class with two entries. Note that the base class is included to allow the framework to continue searching for a given handler if one does not exist within this class. Every standard Windows message has a macro of the form ON_WM_xxx, where xxx is the name of the message. A simple convention is used to generate the handler function name. The name of the function starts with "On." This is followed by the name of the message with the "WM_" removed and only the first letter of each word capitalized. In the following example, the handler name would be OnCreate:
BEGIN_MESSAGE_MAP(CMyView, CView)
ON_WM_CREATE()
ON_COMMAND(ID_APPLY_SEQUENCE, OnApplySequence)
END_MESSAGE_MAP()
You can add a message map entry by using ClassWizard or the WizardBar in Developer Studio. Alternatively, you can add the entry manually.
Self-Check Questions
1. Which one of the following statements is true about MFC's relationship to the Win32 API?
A. The current version of MFC does not wrap any of the Windows operating system extensions.
B. MFC represents a high-level encapsulation of the Windows API.
C. A program can easily mix MFC- and API-level calls.
D. MFC completely encapsulates the Windows API, freeing the developer from all SDK dependence.
2. Which one of the following is not a potential benefit of MFC?
A. MFC reduces complexity by providing a higher-level abstraction of Windows.
B. MFC simplifies database programming through the DAO and ODBC classes.
C. A developer needs less knowledge and skill to program with MFC than with the Windows SDK.
D. MFC displays many of the stronger features of the C++ language, including support for object-oriented
techniques, stronger type checking, exception handling, and so on.
3. Which one of the following is a primary function of the application class?
A. It starts the application’s message loop.
B. It forms the primary window for the application.
C. It acts as a binder for the frame, view, and document objects and a set of GUI resources in an application.
D. It contains member functions to enumerate through all the views in an application.
4. Which one of the following is not considered to be one of the main classes that comprise the application framework?
A. CObject
B. CWinApp
C. CView
D. CFrameWnd
No comments:
Post a Comment