- Table of Contents
- Copyright
- About the Authors
- About the Contributors
- Acknowledgments
- Tell Us What You Think!
- Introduction
- How to Use This Book
- What You Need to Use This Book
- What's New in Visual C++ 6.0
- Contacting the Main Author
- Part I: Introduction
- Chapter 1. The Visual C++ 6.0 Environment
- Part II: MFC Programming
- Chapter 2. MFC Class Library Overview
- Chapter 3. MFC Message Handling Mechanism
- Chapter 4. The Document View Architecture
- Chapter 5. Creating and Using Dialog Boxes
- Chapter 6. Working with Device Contexts and GDI Objects
- Chapter 7. Creating and Using Property Sheets
- Chapter 8. Working with the File System
- Chapter 9. Using Serialization with File and Archive Objects
- Part III: Internet Programming with MFC
- Chapter 10. MFC and the Internet Server API (ISAPI)
- Chapter 11. The WinInet API
- Chapter 12. MFC HTML Support
- Part IV: Advanced Programming Topics
- Chapter 13. Using the Standard C++ Library
- Chapter 14. Error Detection and Exception Handling Techniques
- Chapter 15. Debugging and Profiling Strategies
- Chapter 16. Multithreading
- Chapter 17. Using Scripting and Other Tools to Automate the Visual C++ IDE
- Part V: Database Programming
- Chapter 18. Creating Custom AppWizards
- Chapter 19. Database Overview
- Chapter 20. ODBC Programming
- Chapter 21. MFC Database Classes
- Chapter 22. Using OLE DB
- Chapter 23. Programming with ADO
- Part VI: MFC Support for COM and ActiveX
- Chapter 24. Overview of COM and Active Technologies
- Chapter 25. Active Documents
- Chapter 26. Active Containers
- Chapter 27. Active Servers
- Chapter 28. ActiveX Controls
- Part VII: Using the Active Template Library
- Chapter 29. ATL Architecture
- Chapter 30. Creating COM Objects Using ATL
- Chapter 31. Creating ActiveX Controls Using ATL
- Chapter 32. Using ATL to Create MTS and COM+ Components
- Part VIII: Finishing Touches
- Chapter 33. Adding Windows Help
- Part IX: Appendix
Creating an MFC Application with MFC AppWizard
To kick off your examination of the application framework, you will create the first sample application to illustrate the things that MFC AppWizard can do for you and to provide concrete examples of the MFC application framework.
You will create the HiMom sample included on the CD-ROM, using MFC AppWizard. In a way, this will be a "hello world!" program for MFC, but it also provides much more support for building real applications, so I didn't think HelloWorld would be an appropriate name. (Also, it just so happens that I'd rather say "hi" to my mom than to the rest of the world.) If you would rather use your own application, bear in mind that MFC AppWizard will name many classes and files based on your application name—if your application name is different, so will the names of your classes and files be different.
Starting MFC AppWizard
To start a new project with Visual C++, you create a new project workspace. To do this, select the New command from the File menu and choose the Projects tab. This will dis play the New Projects dialog box shown in Figure 2.1.
Figure 2.1 The New Projects dialog box.
For this example, you use the MFC AppWizard (exe), so make sure it is highlighted in the list box on the left. Next, put the name of your project (HiMom) in the Project name box. Be careful to choose a name here that you can live with; MFC AppWizard will use it to create many class names and filenames and may use some awkward abbreviations. You may also need to be careful about using filenames longer than the 8.3 DOS standard. Long filenames are very useful, and Visual C++ and Win32 operating systems have no problem working with them. However, if you have any tools that support only the 8.3 format, it is much easier to adjust the filenames now.
If you don't like the location that MFC AppWizard has picked for your project, you can change it now by entering a new path in the Location box or using the Browse button to pick a new spot. You may also choose whether to create the project as part of a brand new workspace, or as part of the current workspace. If you choose to add the new project to the current workspace, you may create the new project as a dependency of an existing project in the current work space by checking Dependency of: and selecting a dependent project in the drop-down list. When you are satisfied with your choices, click OK to start MFC AppWizard, which will begin with the wizard page shown in Figure 2.2.
Figure 2.2 MFC AppWizard—Step 1.
This wizard page allows you to select the type of application you would like to create. For this example, you will use Multiple Documents, which will create an application structure that you may have seen in Word or Excel, where you may view several documents at the same time. For reasons you can well imagine, your sample application will not provide quite as much functionality as MS Word or Excel, but it will allow multiple documents.
Single document applications are similar, but they allow only one open document at a time. You will learn some other differences in Chapter 4, "The Document View Architecture," where you will start to dig into the document view architecture.
The third choice, Dialog Based applications, does not use the document view architecture at all. These applications are based on a dialog resource. This is useful for small utility applications, but if you plan to implement menus, toolbars, or printing, you should seriously consider using one of the document-based types, because they can implement many of these things for you much easier than you can add these features to dialog-based applications.
By default, single document and multiple document applications are created with Document View support, and the associated checkbox is selected for you automatically. In most cases, you should leave this checkbox selected, since it enables you to take advantage of the built-in Document View architecture offered by MFC.
For an application type other than multiple document, the following steps will be slightly different, but I think you will get the picture. If you do have a question about any step, you can press F1 to bring up help on the current page. This applies not only to MFC AppWizard, but to most other areas of Developer Studio as well.
For this example, you will use English as the language of choice for your resources, but if you want, you may choose any other language offered.
By now, you have probably noticed the row of buttons along the bottom of the dialog box. The Back and Next buttons allow you to navigate between the pages of MFC AppWizard. If you just remembered that you really wanted to change something in a previous step, you can easily go back and change it. When you have entered your selections in a page, click Next to go to the next step. If you know that you want to use the default settings for the rest of the steps, you could click Finish to go straight to the end. For the HiMom sample, you could do this now, because you are going to use only the defaults, but let's take a look at the other options available. The Cancel button enables you to exit MFC AppWizard without creating a new project.
By clicking on the Next button, you can move to the next page, which looks like Figure 2.3.
Figure 2.3 MFC AppWizard—Step 2.
This page allows you to select options for database support in your application. Obvi ously, if you select None, you will get none (from MFC AppWizard anyway—you can always add things later, but you have to do it manually). The Header Files Only option includes the AFXDB.H header file, which includes simple database support, allowing you to create and use recordsets to work with databases.
The two database view options create a view class for your application based on CRecordView, which gives you a form-based application allowing you to view and update records. The Database View With File Support option supports document serialization. If you choose either of these options, you must also choose a data source. You learn about this in much greater detail in Part V, "Database Programming," so let's go ahead to the next page, shown in Figure 2.4.
Figure 2.4 MFC AppWizard—Step 3.
With this page, you can select options that allow your application to support various levels of Object Linking and Embedding (OLE). Once again, if you select None, that's just what you'll get. You have to add OLE support manually if you change your mind after the application is created. You will explore OLE, COM, and ActiveX in much greater detail later, but here's the short version of what the other options mean:
- Container support allows your application to support the embedding of OLE objects. This enables your application to serve as an OLE container just like Word and Excel.
- Mini-server applications can create and manage compound document objects, but they cannot run stand-alone, supporting only objects that are embedded in OLE container applications.
- Full-server applications can also create and manage compound document objects, as well as running stand-alone and supporting both linked and embedded items.
- Select Both Container and Server if you want your application to be able to accept embedded or linked objects into its own documents and be able to create OLE objects for use in container applications.
- If you have selected any of the server options, you can also make your application an ActiveX document server.
- Likewise, if you have selected any of the container options, you can make your application an ActiveX document container.
- If you select support for compound files, MFC will serialize your container application's documents using the OLE compound-file format. If you choose "No, thank you," it won't.
- You can select Automation to allow automation clients, such as Word, Excel, and the Windows Scripting Host, to access your application.
- If you want to include ActiveX controls in your application, such as those provided in the component gallery, select the ActiveX Controls option.
Step 4, shown in Figure 2.5 allows you to select several advanced features that MFC AppWizard can add for you.
Figure 2.5 MFC AppWizard—Step 4.
Selecting Docking Toolbar allows the user to move the toolbar from its default location and dock it to the borders of the window.
The Initial Status Bar option provides a status bar, including keyboard state indicators and help for menus and toolbars. This also adds menu commands to hide or display the status bar and toolbar.
The Printing and Print Preview option tells MFC AppWizard to generate code and menu commands to handle printing tasks automatically.
The Context-Sensitive Help option generates help files that you can use to give your users help on specific areas of your application.
If you select 3D Controls, all controls in your application will have that nifty chiseled look.
You can include support for the Windows Open Services Architecture (WOSA) by selecting the MAPI (Messaging API) option, which allows your application to integrate with mail systems, or the Windows Sockets option, which enables TCP/IP communications.
If you have selected the Docking Toolbar option, you can select the type of toolbar to be used—you can select either a Normal Win32 toolbar, or an Internet Explorer ReBar toolbar.
MFC AppWizard automatically implements a most-recently-used file list for you in the File menu. You may set the number of files here to keep in this list.
The Advanced button allows you to select preferences about document types and win dow styles for your application.
Step 5, shown in Figure 2.6, allows you to tell MFC AppWizard to include source file comments where appropriate.
Figure 2.6 MFC AppWizard—Step 5.
You can also specify the type of project that is to be built. By default, an MFC Standard application is created. Optionally, you can select the Windows Explorer option, which creates a splitter window containing a tree view in the left pane, and a list view in the right pane.
This page also gives you the option to use the shared DLL versions of MFC or the statically linked library. If you know that your application will be the only MFC app running at any given time, you may want to use the static libraries, but it is generally better to use the DLL versions, which can be shared by all applications. Using the DLL versions also reduces the disk and memory requirements of your application's executable file.
Step 6, shown in Figure 2.7 shows the classes that MFC AppWizard will create for you.
Figure 2.7 MFC AppWizard—Step 6.
If you like, you can change the defaults that MFC AppWizard supplies by selecting the class in the top list and editing the fields below. For many of the classes, options will be inactive (grayed). In most of these cases, changing the default doesn't make sense anyway—an application class based on anything other than CWinApp just wouldn't work well with MFC.
If you don't like the filenames that MFC AppWizard has chosen, you may freely change these (for all but the app class), but you can place only one of the classes in each file.
For MDI applications, you can change only the base class of your view class. You prob ably will not want to use the base CView class in a real application, but will want to use one of the available derived classes that provide much greater functionality. For more on MFC's view classes, see Chapter 4.
Click Finish here, and you're just about done. MFC AppWizard will display a window like Figure 2.8.
Figure 2.8 The New Project Information dialog box.
You should review the information presented here to see that it matches the options you selected. If you find that something here doesn't match what you wanted, click Cancel to go back to Step 6. If you are satisfied with your choices, click OK and let MFC AppWizard do the work for you.
You now have a complete Windows application. You can see this for yourself by choosing the Build HiMom.exe command from the Build menu to compile and link, then choosing the Execute HiMom command from the Build menu to run it. You will notice that many cool functions that you expect from a Windows application have already been implemented for you, such as File, New, and Print Preview. Now all you have to do is the really good stuff to fit your application.
Getting to Know Your New Application
Okay, so you clicked a few buttons and got this little app with a bunch of menus that don't do anything. What's it got under the hood? Here, you will look at what MFC AppWizard has created for you and how the application framework that was created provides a solid backbone for your application.
If you're like me, your first instinct may be to open a DOS window and start digging through files. Sure, you can still do this, but it really is easier to use the Project Workspace window—I promise. Remember that you can open any source file, usually to just the right place, by double-clicking on the file or class view of the project workspace.
Classes Created by MFC AppWizard
As you may have already noticed, MFC AppWizard has created a handful of classes for you, based on your application's name. These fall into the basic classes of Application classes, Document classes, View classes, and Frame classes. Each class is based on one of the classes in the application architecture hierarchy. (You will almost never use the base classes directly, but will derive your own classes from them.) The HiMom example you just created will implement the classes shown in Table 2.1.
Table 2.1. Classes for HiMom
| MFC Base Class | Derived Class | Filename |
| CWinApp | CHiMomApp | HiMom.cpp |
| CDialog | CAboutDlg | HiMom.cpp |
| CDocument | CHiMomDoc | HiMomDoc.cpp |
| CView | CHiMomView | HiMomView.cpp |
| CFrameWnd | CMainFrame | MainFrm.cpp |
| CMDIChildWnd | CChildFrame | ChildFrm.cpp |
CDocument, CView, and Frame Classes
The classes that you derive from CDocument are intended to hold the data that your application will work with. Your CDocument class will be responsible for reading and writing data files and will serve as a repository for the information that your CView classes will allow the user to view and manipulate. You may choose not to use these classes and the document view architecture, but you will see in Chapter 4, "The Document View Architecture," that these are very useful in helping you implement many functions common to Windows applications.
Classes based on CMainFrame will implement the main frame for your application. (Kinda makes sense, I suppose.) It is this class that will manage the menus, toolbars, and status bars (even the main window itself) for the main window of your application. Classes derived from CChildFrame are used in MDI applications to manage the child windows created for multiple views. Like the main frame, CChildFrame classes can manage menus, toolbars, status bars, and the window for the children of your main frame. You will look at how the document, view, and frame classes work together in Chapter 4, so let's leave it at that for now and move on to the real heart of your MFC application.
The CWinApp Class | Next Section

Account Sign In
View your cart