A Few Words About MFC


In 1992, Microsoft released MFC 1.0 as part of the Programmer's Workbench. MFC was a set of about 60 classes targeted mainly at wrapping the windowing and drawing parts of the 16-bit Windows API. Its goal was to wrap the implicit and inconsistent object models inherent in the operating system with an explicit, consistent C++ object model, and it did as good a job as could be expected given the state of Microsoft's C++ compiler at the time. [1]

[1] At the time, Microsoft's C++ compiler was far behind the pack in the implementation of things such as templates, exceptions, and runtime type identification (RTTI). This tardiness caused ripples in the design of MFC, and in the Windows C++ programmer community, that can still be felt to this day.

In 2002, Microsoft released MFC 7.0 as part of Visual Studio .NET 2002. MFC had grown to more than 200 classes, and, along the way, its goal had expanded: to provide a complete C++ object model replacement of the Win32 API. As of version 7.0, MFC grew to be the most feature-rich way to build commercial-quality client- tier applications in Windows. [2] Here's a list of the major features that MFC programmers have grown to rely on:

[2] It also grew on the server side, but MFC has always been firmly grounded on the client.

  • Support for dialog-based, SDI, multi-SDI, and MDI applications

  • Document-View Architecture

  • Printing, print setup, and print preview

  • Floating toolbars , status bars, and dialog bars

  • Context-sensitive help

  • Object Linking and Embedding (both client and object)

  • OLE Automation

  • COM control hosting

  • Active Document servers

  • Full integration into VS.NET, including four of the most comprehensive wizards that the IDE provides

  • Dynamic Data Exchange and Validation

  • Command routing

  • Command UI updating

  • Windows logo compliance

  • Shell integration (icons, drag and drop, DDE, and command line parsing)

  • Wrappers for a large percentage of the Win32 API, including windowing, drawing, databases, sockets, Registry access, the file system, threading, and more

  • Auto-upgrade from 16 bits to 32 bits [3]

    [3] This isn't important now, but man oh man, it was a big deal when we were all busy porting our 16-bit applications to 32 bits.

  • Tons of third-party and community support

If you've read the rest of this book, you'll notice that MFC provides a lot of features that I didn't talk about. If you're starting with this appendix as an MFC programmer wondering what WinForms does and doesn't offer, you may be disappointed to hear that I haven't covered all the features in this list (although I certainly have covered a number of them). Either way, the hard, cold truth is that MFC provides more features than WinForms does for building stand-alone, document-based applications.

For example, if you want to build a text editor, you can do that in MFC by running a wizard, choosing the right options, and writing only a few lines of code. By running the wizard, you get an application to start with that includes a status bar, a toolbar (floating), all the File, Edit, and Help menu items implemented (including a most recently used file list, printing, and context-sensitive help), all in a fully logo-compliant SDI, multi-SDI, or MDI application, based on your whim that day. As a document-based application framework, MFC has no peer.

However, in recent years the world seems to have moved away from document-based applications. Relatively few folks seem interested in building text editors or word processors or spreadsheets. Instead, the bulk of the applications are either completely HTML-based or n-client applications talking to network, database, or Web services back ends. It's for this use that .NET as a whole and WinForms specifically have been tailored.

That's not to say that WinForms can't be used to build darn nice document-based applications. In fact, because WinForms is only a small piece of the more than 2,000 public classes provided in .NET, it's likely that if what you're looking for isn't in WinForms, it's found somewhere else in .NET. For example, WinForms itself (the System.Windows.Forms namespace) doesn't provide any custom drawing support at all. Instead, GDI+ (in the System.Drawing namespace) supplies that functionality.

And this is the chief difference between MFC and WinForms. MFC was meant as a replacement for the underlying Win32 API, but that didn't stop the Win32 API from growing. In fact, as much as MFC has grown over the years, the functionality of the underlying OS has increased at least tenfold. WinForms, on the other hand, is meant to be a replacement only for the windowing part of Win32. It's the rest of the .NET Framework classes that are meant to replace the rest of Win32. Of course, .NET will never replace the entire Win32 API, but because most new functionality is slated to be added to .NET in the future, it's clear that betting on the future of .NET is a wise wager.



Windows Forms Programming in C#
Windows Forms Programming in C#
ISBN: 0321116208
EAN: 2147483647
Year: 2003
Pages: 136
Authors: Chris Sells

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