This is a continuation from the previous module . Program examples compiled using Visual C++ 6.0 (MFC 6.0) compiler on Windows XP Pro machine with Service Pack 2. Topics and sub topics for this Tutorial are listed below:
The Gallery
The Visual C++ Components and Controls Gallery lets you share software components among different projects. The Gallery manages three types of modules:
Figure 18: Visual C++ Components and Controls Gallery.
If you decide to use one of the prepackaged Visual C++ components, try it out first in a dummy project to see if it's what you really want. Otherwise, it might be difficult to remove the generated code from your regular project. All user-generated Gallery items can be imported from and exported to OGX files . These files are the distribution and sharing medium for Visual C++ components.
ATL is a tool, separate from MFC, for building ActiveX controls. You can build ActiveX controls with either MFC or ATL, but ATL controls are much smaller and quicker to load on the Internet.
The Microsoft Foundation Class Library
The Microsoft Foundation Class Library (the MFC library, for short) defines the application framework that you'll be learning in this Tutorial. MFC provides a variety of classes designed to serve a wide range of needs. You'll find a handy diagram of the MFC 7.0 class hierarchy here . The majority of MFC classes are derived, either directly or indirectly, from CObject . CObject provides other useful benefits to its derived classes as well. For example, it overloads the new and delete operators to provide protection against memory leaks. If you create an object from a CObject -derived class and fail to delete it before the application terminates, MFC will warn you by writing a message to the debug output window. The overarching importance of this most basic of MFC classes will become increasingly clear as you grow more familiar with MFC.
One definition of application framework is "an integrated collection of object-oriented software components that offers all that's needed for a generic application." That isn't a very useful definition, is it? If you really want to know what an application framework is, you'll have to read the rest of this book. The application framework example that you'll familiarize yourself with later in this chapter is a good starting point.
An Application Framework vs. a Class Library
One reason that C++ is a popular language is that it can be "extended" with class libraries. Some class libraries are delivered with C++ compilers, others are sold by third-party software firms, and still others are developed in-house. A class library is a set of related C++ classes that can be used in an application. A mathematics class library, for example, might perform common mathematics operations, and a communications class library might support the transfer of data over a serial link. Sometimes you construct objects of the supplied classes; sometimes you derive your own classes, it all depends on the design of the particular class library.
An application framework is a superset of a class library. An ordinary library is an isolated set of classes designed to be incorporated into any program, but an application framework defines the structure of the program itself. Microsoft didn't invent the application framework concept. It appeared first in the academic world, and the first commercial version was MacApp for the Apple Macintosh. Since MFC 2.0 was introduced, other companies, including Borland, have released similar products.
An Application Framework Example
It's time to look at some code, not pseudocode but real code that actually compiles and runs with the MFC library. It's the good old "Hello, world!" application, with a few additions. It's about the minimum amount of code for a working MFC library application for Windows. You don't have to understand every line now. This is Single Document Interface (SDI) without Document /View architecture support application and the full steps to build this program are given in Example 1. By convention, MFC library class names begin with the letter C. Following is the source code for the header and implementation files for our MYAPP application (all the Visual C++ comments have been deleted). The classes CMyApp and CMyFrame are each derived from MFC library base classes. The first is the MyApp.h header file for the MYAPP application:
class CMyApp : public CWinApp
virtual BOOL InitInstance();
// frame window class
class CMyFrame : public CFrameWnd
// "afx_msg" indicates that the next two functions are part
// of the MFC library message dispatch system
afx_msg void OnLButtonDown(UINT nFlags, CPoint point);
afx_msg void OnPaint();
And here is the MyApp.cpp implementation file for the MYAPP application:
#include // MFC library header file declares base classes
CMyApp theApp; // the one and only CMyApp object
m_pMainWnd = new CMyFrame();
Create(NULL, "MYAPP Application");
void CMyFrame::OnLButtonDown(UINT nFlags, CPoint point)
TRACE("Entering CMyFrame::OnLButtonDown - %lx, %d, %d\n", ( long ) nFlags, point.x, point.y);
CPaintDC dc( this );
dc.TextOut(0, 0, "Hello, world!");
Here are some of the program elements:
The WinMain() function : Remember that Windows requires your application to have a WinMain() function. You don't see WinMain() here because it's hidden inside the application framework.
The CMyApp class : An object of class CMyApp represents an application. The program defines a single global CMyApp object, theApp . The CWinApp base class determines most of theApp 's behavior.
Application startup : When the user starts the application, Windows calls the application framework's built-in WinMain() function, and WinMain() looks for your globally constructed application object of a class derived from CWinApp . Don't forget that in a C++ program global objects are constructed before the main program is executed.
The CMyApp::InitInstance member function : When the WinMain() function finds the application object, it calls the virtual InitInstance() member function, which makes the calls needed to construct and display the application's main frame window. You must override InitInstance() in your derived application class because the CWinApp base class doesn't know what kind of main frame window you want.
The CWinApp::Run member function : The Run() function is hidden in the base class, but it dispatches the application's messages to its windows, thus keeping the application running. WinMain() calls Run() after it calls InitInstance() .
The CMyFrame class : An object of class CMyFrame represents the application's main frame window. When the constructor calls the Create() member function of the base class CFrameWnd , Windows creates the actual window structure and the application framework links it to the C++ object. The ShowWindow() and UpdateWindow( ) functions, also member functions of the base class, must be called in order to display the window.
The CMyFrame::OnLButtonDown function : This function is a sneak preview of the MFC library's message-handling capability. We've elected to "map" the left mouse button down event to a CMyFrame member function. You'll learn the details of the MFC library's message mapping in Module 3. For the time being, accept that this function gets called when the user presses the left mouse button. The function invokes the MFC library TRACE macro to display a message in the debugging window.
The CMyFrame::OnPaint function : The application framework calls this important mapped member function of class CMyFrame every time it's necessary to repaint the window: at the start of the program, when the user resizes the window, and when all or part of the window is newly exposed. The CPaintDC statement relates to the Graphics Device Interface (GDI) and is explained in later chapters. The TextOut() function displays " Hello, world! ".
Application shutdown : The user shuts down the application by closing the main frame window. This action initiates a sequence of events, which ends with the destruction of the CMyFrame object, the exit from Run() , the exit from WinMain() , and the destruction of the CMyApp object.
Look at the code example again. This time try to get the big picture. Most of the application's functionality is in the MFC library base classes CWinApp and CFrameWnd . In writing MYAPP, we've followed a few simple structure rules and we've written key functions in our derived classes. C++ lets us "borrow" a lot of code without copying it. Think of it as a partnership between us and the application framework. The application framework provided the structure, and we provided the code that made the application unique. Now you're beginning to see why the application framework is more than just a class library. Not only does the application framework define the application structure but it also encompasses more than C++ base classes. You've already seen the hidden WinMain() function at work. Other elements support message processing, diagnostics, DLLs, and so forth.
The notation used in MFC is mix of the Hungarian and CamelCase . If you already got familiar with the MFC/Windows programming, you will recognize the codes such as variables, classes, objects etc. based on the notations used. For example, MFC library class names begin with the letter C such as CScrollView and variables prefixed with m_ .
Object ID Naming Conventions
There are several categories or types of IDs found in Windows applications. The MFC ID-naming convention defines different prefixes for different resource types. MFC uses the prefix "IDR_" to refer to a resource ID that applies to multiple resource types. For example, for a given frame window, the same " IDR_" value is used to refer to a menu, accelerator, string and icon resource all at once.
Description
Multiple resource types (Used for Menus, Accelerators primarily).
For dialog template resources (for example, IDD_DIALOG1).
For Cursor resources.
For Icon resources.
For Bitmap resources.
For String resources.
Note that the IDS_ value for a string resource is the ID passed to LoadString. The actual implementation of string table resources groups together 16 strings into one segment. For example, within a DIALOG resource, we follow the convention of:
Description
For standard push button IDs.
For other dialog controls.
The "IDC_" prefix is also used for cursors. This naming conflict is not usually a problem since a typical application will have few cursors and a large number of dialog controls. Within a Menu resource, we follow the convention of:
Description
For menu items not using the MFC command architecture.
For menu item commands using the MFC command architecture.
Commands that follow the MFC command architecture must have an ON_COMMAND command handler and may have an ON_UPDATE_COMMAND_UI handler. If these command handlers follow the MFC command architecture, they will function correctly whether they are bound to a menu item, a toolbar button or a dialog bar button. The same ID_ is also used for a menu prompt string displayed on the program's message bar. Most of the menu items in your application should follow the MFC command convention. All of the standard command IDs (for example, ID_FILE_NEW) follow this convention. MFC also uses "IDP_" as a specialized form of strings (that is, instead of "IDS_"). Strings with the "IDP_" prefix are "prompts," that is, strings used in message boxes. "IDP_" strings may contain "%1" and "%2" as place holders of strings determined by the program. "IDP_" strings usually have help topics, while "IDS_" strings do not. "IDP_" strings are always localized, while "IDS_" strings may or may not be localized. The MFC library also uses the "IDW_" prefix as a specialized form of control IDs (that is, instead of "IDC_"). These IDs are assigned to child windows such as views and splitters by the framework classes. MFC implementation IDs are prefixed with "AFX_".
Object ID-Numbering Convention
The following lists the valid ranges for the IDs of the specific types. Some of the limits are technical implementation limits while others are just conventions to prevent your IDs from colliding with Windows predefined IDs or MFC default implementations. We strongly recommend you do not defined IDs outside the recommended ranges. Even though the lower limit of many of these ranges is 1 (0 is not used), common convention starts practical use of IDs at 100 or 101.
