Why Use the 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 application framework

  • Use another Windows-based application framework such as Borland's Object Windows Library (OWL)

If you're starting from scratch, any option involves a big learning curve. If you're already a Win16 or Win32 programmer, you'll still have a learning curve with the MFC library. Since its release, MFC 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 C++ Microsoft Windows API. If you accept the premise that the C++ language is now the standard for serious application development, you'd have to say that it's natural for Windows to have a C++ programming interface. What better interface is there than the one produced by Microsoft, creator of Windows? That interface is the MFC library.

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 kilobytes (KB) in size. Today, Windows programs are larger. One reason is that 32-bit code is fatter. Even with the large memory model, a Win16 program used 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 new 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 expect in modern programs. 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 runtime 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 while the support DLLs are loaded.

The Visual C++ tools reduce coding drudgery. The Visual C++ resource editors, AppWizard, and ClassWizard significantly reduce the time needed to write code that is specific to your application. For example, the resource editor creates a header file that contains assigned values for #define constants. App-Wizard generates skeleton code for your entire application, and ClassWizard generates prototypes and function bodies for message handlers.

The MFC library application framework is feature rich. The MFC library version 1.0 classes, introduced with Microsoft C/C++ version 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 version 1.0

The MFC library version 2.0 classes (in Visual C++ version 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 menu items 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 version 1.0

  • DLL support

The MFC library version 2.5 classes (in Visual C++ version 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, FoxPro, and Microsoft SQL Server

  • An interface to OLE version 2.01, with support for in-place editing, linking, drag and drop, and OLE Automation

Visual C++ version 2.0 was the first 32-bit version of the product. It included support for Microsoft Windows NT version 3.5. It also contained MFC version 3.0, which had the following new features:

  • Tab dialog (property sheet) support (which was also added to Visual C++ version 1.51, included on the same CD-ROM)

  • 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 MFC 3.1, added the following:

  • Support for the new Microsoft 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++ version 3.0 and proceeded directly to 4.0 in order to synchronize the product version with the MFC version. MFC 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 MFC version 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 MFC version 4.21, which fixed some 4.2 bugs. Visual C++ 5.0 introduced some worthwhile features of its own as well:

  • A redesigned IDE, 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

The latest edition of Visual C++, 6.0, includes MFC 6.0. (Notice that the versions are now synchronized again.) Many of the features in MFC 6.0 enable the developer to support the new Microsoft Active Platform, including the following:

  • MFC classes that encapsulate the new Windows common controls introduced as part of Internet Explorer 4.0

  • Support for Dynamic HTML, which allows the MFC programmer 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 Active Data Objects (ADO) data binding, which help database developers who use MFC or ATL

The Learning Curve

All the listed benefits sound great, don't they? 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 have to learn C++, Windows, and the MFC library (without OLE) all at the same time, it will take at least six months before you're 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 our own experience, we 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 programming down 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.



Programming Visual C++
Advanced 3ds max 5 Modeling & Animating
ISBN: 1572318570
EAN: 2147483647
Year: 1997
Pages: 331
Authors: Boris Kulagin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net