In this post, we are defining ActiveX Classes, Category Common classes, Database Classes, Client-Side Classes, SDI and MDI Applications, Document/View Architecture, Message Maps and provide some self-check questions.
ActiveX Classes
MFC provides classes that simplify the process of adding ActiveX capabilities to your applications and significantly reduce development time. The ActiveX classes work with the other application framework classes to provide easy access to the ActiveX API. Using the ActiveX classes, you can:
- 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.
Note This course does not cover creating ActiveX components. For information about how to create and modify ActiveX components using MFC, see Mastering MFC Development Using Visual C++ 5, listed in the Library.
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
ActiveX control classes COleControlModule, COleControl, CConnectionPoint, CPictureHolder, CFontHolder, COlePropertyPage, CPropExchange, CMonikerFile, CAsyncMonikerFile, CDataPathProperty, CCachedDataPathProperty, COleCmdUI, COleSafeArray
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
Accessing data and connecting to databases are two of the most common Windows environment programming tasks. MFC provides classes that enable operations on databases through Open Database Connectivity (ODBC) and the data access objects (DAO).
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.
CDatabase and CDaoDatabase
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: Dyna-sets and snapshots. A Dyna-set 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
Creating applications that interact with the Internet, intranets, or both, is becoming a major focus for developers. MFC includes the WinInet APIs and the Internet Server API (ISAPI), which provide classes for client-side and server-side applications, respectively.
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 Classes
This table describes MFC Internet classes related to client-side applications.
Class Description
CInternetSession Creates and initializes one or more simultaneous Internet sessions. Specific application-level services can be established by using the member functions GetHttpConnection, GetFtpConnection, and GetGopherConnection.
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 server-side applications.
Class Description
CHttpServer Use this class to create and manage a server extension DLL, also known as an Internet server application (ISA). ISAs are used to extend an Internet server’s capabilities.
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.
Global Afx Functions
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
AfxAbort() Unconditionally terminates an application.
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
MFC provides an application framework on which you can build applications for Windows. The framework provides a set of starter files for an application and supplies standard user-interface features that you can implement in your application. You provide the rest of the code, specifically those things needed for your application.
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
The MFC document/view architecture provides a single, consistent way of coordinating application data, referred to as a document, and views of that data. A document is a data object with which the user interacts in an editing session. A view is a window object through which the user interacts with the document. This topic provides a broad overview of document/view architecture. For detailed information, see Chapter 4: Creating MFC Applications.
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.
SDI and MDI Applications
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.
Note Under Windows 95, applications will increasingly be SDI as the operating system moves toward a “document-centered” view. This course teaches you how to create SDI applications using MFC. For information about how to create MDI applications, see Mastering MFC Development Using Visual C++ 5 listed in the Library.
Objects in an SDI Application
Document/view architecture provides the framework for documents and views in the base classes CDocument and CView. The CWinApp, CFrameWnd, and CDocTemplate classes work in conjunction with CDocument and CView to ensure that all the pieces of the application fit together. You will learn more about how to implement these classes in an application in later chapters.
The following table lists the application objects and related classes in an SDI application and describes the major tasks each object performs.
Object Description
Document Your document class (derived from CDocument) specifies your application’s data.
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 CFrameWnd class. In an SDI application, the document frame window is also the mainframe 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.
Non-Document/View Architecture
Although most of the discussion about Visual C++ and MFC functionality assumes the 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. The mainframe 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, the mainframe (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
Communication between the operating system, applications, and application components is conducted through various types of messages. For example, when creating an instance of an application, the operating system sends a series of messages to the application, which then responds appropriately to initialize itself. Keyboard and mouse activity causes the operating system to generate messages and send them to the proper application. User-interface components, such as command buttons and list boxes, generate messages to their parent windows.
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
- 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 dependency. - 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. - 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. - 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
