Windows Forms 2.0 Programming (Microsoft .NET Development Series)

In 1992, Microsoft released Microsoft Foundation Classes (MFC) 1.0 as part of the Programmer's Workbench. MFC was a set of approximately 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 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 tool strips, status strips, and dialog bars

  • Context-sensitive help

  • Object Linking and Embedding (both client and server)

  • OLE Automation

  • COM control hosting

  • Active Document servers

  • Full integration into VS05, 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 some features that I didn't discuss. If you're starting with this appendix as an MFC programmer wondering what Windows Forms does and doesn't offer, you may be disappointed to discover that I haven't covered all the features in this list (although I have covered a number of them). Either way, the hard, cold truth is that MFC provides more features than Windows Forms 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 strip, a tool strip (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 are n-tier client applications talking to network, database, or Web services back ends. It's for this use that .NET as a whole and Windows Forms specifically have been tailored.

That's not to say that Windows Forms can't be used to build darn nice document-based applications. In fact, because Windows Forms is only a small piece of the huge number of public classes provided in .NET, if what you're looking for isn't in Windows Forms, it's probably found elsewhere in .NET. For example, Windows Forms 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 Windows Forms. 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. Windows Forms, 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 much more functionality has been added to Windows Forms 2.0 and.NET Framework 2.0, it's clear that placing your eggs in the .NET basket is a wise investment, particularly as we move toward the next-generation Windows Presentation Framework.

Related

Категории