لطفا منتظر باشید ...
This chapter introduces the Microsoft Foundation Class (MFC) library 7.0 application framework and explains its benefits. It includes a stripped-down but fully operational MFC library program for Microsoft Windows that should help you understand what application framework programming is all about. I'm keeping theory to a minimum here, but I've included sections on message mapping and on documents and views to help you understand the examples in later chapters.
Why Use This Application Framework?
If you're going to develop applications for Windows, you've got to choose a development environment. Assuming that you've already rejected non-C options such as Microsoft Visual Basic and Borland Delphi, here are some of your remaining options:
Program in C with the Win32 API.
Write your own C++ Windows class library that uses Win32.
Use the MFC library application framework.
Use another Windows-based application framework. (Most of them are defunct, however—such as Borland's Object Windows Library [OWL].)
| Note | We'll cover .NET Windows Forms in Part VI of this book. |
If you're starting from scratch, any option will involve a big learning curve. If you're already a Win32 programmer, you'll still have a learning curve with the MFC library. Since its release, the MFC library has become the dominant Windows class library. But even if you're familiar with it, it's still a good idea to step through the features of this programming choice.The MFC library is the low-level C++ interface to the Windows API C++ has been a standard for many developers for a number of years. It's turned into a mature, well-understood framework with great third-party support. If you need the highest-performance applications, your applications must live as closely to the Windows API as possible. C++ and MFC are as close as you can get without writing WndProc methods by hand. Application framework applications use a standard structure Any programmer starting on a large project develops some kind of structure for the code. The problem is that each programmer's structure is different, and it's difficult for a new team member to learn the structure and conform to it. The MFC library application framework includes its own application structure—one that's been proven in many software environments and in many projects. If you write a program for Windows that uses the MFC library, you can safely retire to a Caribbean island, knowing that your minions can easily maintain and enhance your code back home.Don't think that the MFC library's structure makes your programs inflexible. With the MFC library, your program can call Win32 functions at any time, so you can take maximum advantage of Windows.Application framework applications are small and fast Back in the 16-bit days, you could build a self-contained Windows EXE file that was less than 20 KB in size. Today, Windows-based programs are larger. One reason is that 32-bit code is fatter. Even with the large memory model, a Win16 program uses 16-bit addresses for stack variables and many globals. Win32 programs use 32-bit addresses for everything and often use 32-bit integers because they're more efficient than 16-bit integers. In addition, the C++ exception-handling code consumes a lot of memory.That old 20 KB program didn't have a docking toolbar, splitter windows, print preview capabilities, or control container support—features that users now expect. MFC programs are bigger because they do more and look better. Fortunately, it's now easy to build applications that dynamically link to the MFC code (and to C run-time code), so the size goes back down again—from 192 KB to about 20 KB! Of course, you'll need some big support DLLs in the background, but those are a fact of life these days.
As far as speed is concerned, you're working with machine code produced by an optimizing compiler. Execution is fast, but you might notice a startup delay as the support DLLs are loaded.The Visual C++ .NET tools reduce coding drudgery The Visual C++ .NET resource editors, the MFC Application Wizard, and the code wizards available from Class View significantly reduce the time needed to write code that's specific to your application. For example, the resource editor creates a header file that contains assigned values for #define constants. The MFC Application Wizard generates skeleton code for your entire application, and you can use the Properties window to add message handlers and map messages to them.The MFC library application framework is feature rich The MFC library 1.0 classes, introduced with C/C++ 7.0, included the following features:
A C++ interface to the Windows API
General-purpose (non-Windows-specific) classes, including:
Collection classes for lists, arrays, and maps
A useful and efficient string class
Time, time span, and date classes
File access classes for operating system independence
Support for systematic object storage and retrieval to and from disk
A "common root object" class hierarchy
Streamlined Multiple Document Interface (MDI) application support
Some support for OLE 1.0
The MFC library 2.0 classes (in Visual C++ 1.0) picked up where the version 1.0 classes left off by supporting many user interface features that are found in current Windows-based applications, plus they introduced the application framework architecture. Here's a summary of the important new features:
Full support for File Open, Save, and Save As commands and the most recently used file list
Print preview and printer support
Support for scrolling windows and splitter windows
Support for toolbars and status bars
Access to Visual Basic controls
Support for context-sensitive help
Support for automatic processing of data entered in a dialog box
An improved interface to OLE 1.0
DLL support
The MFC library 2.5 classes (in Visual C++ 1.5) contributed the following:
Open Database Connectivity (ODBC) support that allows your application to access and update data stored in many popular databases such as Microsoft Access, Microsoft FoxPro, and Microsoft SQL Server
An interface to OLE 2.01, with support for in-place editing, linking, drag and drop, and OLE Automation
Visual C++ 2.0 was the first 32-bit version of the product. It included support for Microsoft Windows NT version 3.5. It also contained the MFC library 3.0, which had the following new features:
Tab dialog box (property sheet) support (which was also added to Visual C++ 1.51, included on the same CD)
Docking control bars that were implemented within MFC
Support for thin-frame windows
A separate Control Development Kit (CDK) for building 16-bit and 32-bit OLE controls, although no OLE control container support was provided
A subscription release, Visual C++ 2.1 with the MFC library 3.1, added the following:
Support for the new Windows 95 (beta) common controls
A new ODBC Level 2 driver integrated with the Access Jet database engine
Winsock classes for TCP/IP data communication
Microsoft decided to skip Visual C++ 3.0 and proceeded directly to 4.0 in order to synchronize the product version with the MFC library. The MFC library 4.0 contains these additional features:
New OLE-based Data Access Objects (DAO) classes for use with the Jet engine
Use of the Windows 95 docking control bars instead of the MFC control bars
Full support for the common controls in the released version of Windows 95, with new tree view and rich-edit view classes
New classes for thread synchronization
OLE control container support
Visual C++ 4.2 was an important subscription release that included the MFC library 4.2. The following new features were included:
WinInet classes
ActiveX Documents server classes
ActiveX synchronous and asynchronous moniker classes
Enhanced MFC ActiveX Control classes, with features such as windowless activation, optimized drawing code, and so forth
Improved MFC ODBC support, including recordset bulk fetches and data transfer without binding
Visual C++ 5.0 included the MFC library 4.21, which fixed some 4.2 bugs. Visual C++ 5.0 introduced some worthwhile features of its own as well:
A redesigned IDE, Microsoft Developer Studio 97, which included an HTML-based online help system and integration with other languages, including Java
The Active Template Library (ATL) for efficient ActiveX control construction for the Internet
C++ language support for COM (Component Object Model) client programs with the new #import statement for type libraries, as described in Chapter 25.Visual C++ 6.0 includes the MFC library 6.0. (Notice that the versions are synchronized again.) Many of the features in the MFC library 6.0 enabled developers to support the modern platform at the time, the Microsoft Active Platform, including the following:
MFC classes that encapsulate the new Windows common controls introduced as part of Microsoft Internet Explorer 4.0
Support for Dynamic HTML (DHTML), which allows MFC programmers to create applications that can dynamically manipulate and generate HTML pages
Active Document Containment, which allows MFC-based applications to contain Active Documents
OLE DB Consumers and Providers Template support and ActiveX Data Objects (ADO) data binding, which help database developers who use the MFC library or ATL
The latest edition of Visual C++, Visual C++ .NET, includes the MFC library 7.0. Many of the features in the MFC library 7.0 support Internet programming (and the new Microsoft .NET platform) and also improve the Windows development environment. The new features include the following:
Enhanced support for HTML help within MFC applications
Support for windowless controls
DHTML dialog boxes and editing components
HTTP argument management classes
Windows 2000 Print dialog box
Stricter message-handler type checking
Date support beyond the year 2038
The Learning Curve
All the benefits sound great, don't they? But you're probably thinking, "You don't get something for nothing." Yes, that's true. To use the application framework effectively, you have to learn it thoroughly, and that takes time. If you had to learn C++, Windows, and the MFC library (without OLE) all at the same time, it would take at least six months before you were really productive. Interestingly, that's close to the learning time for the Win32 API alone.How can that be if the MFC library offers so much more? For one thing, you can avoid many programming details that C-language Win32 programmers are forced to learn. From my own experience, I can say that an object-oriented application framework makes programming for Windows easier to learn—that is, once you understand object-oriented programming.The MFC library won't bring real Windows-based programming to the masses. Programmers of applications for Windows have usually commanded higher salaries than other programmers, and that situation will continue. The MFC library's learning curve, together with the application framework's power, should ensure that MFC library programmers will continue to be in strong demand.
