MFC Versus WinForms


Some folks do need to build document-based applications, and even though WinForms isn't designed to support that as well as MFC is, it's not very hard to build complete document-based applications if you're armed with the knowledge of what WinForms does and doesn't provide as compared with MFC. Table A.1 shows a feature-based summary focused on building document-based applications.

Table A.1. MFC Versus WinForms/.NET

Feature

MFC

WinForms/.NET

Application Wizards

Four

Four

IDE Integration

Yes

Yes

Dialog, SDI, MDI Applications

Yes

Yes

Multi-SDI Applications

Yes

No

UI Layout

Yes (dialogs only)

Yes

Docking and Splitting

Yes (simple)

Yes

Anchoring

No

Yes

Toolbars and the like

Yes

Yes (no floating)

Printing, Preview, Setup

Yes

Yes

OLE/Active Documents

Yes

No

COM Control Hosting

Yes

Yes

Automation

Yes

Yes (Remoting)

F1 Help

Yes

Yes

DDX/DDV

Yes

Yes (DDX not needed)

Win32 Wrappers

Yes

Yes

Data Binding

Yes (simple)

Yes

Cross-Language

No

Yes

Cross-Platform

No

Yes

Cross-Bitness

16/32

32/64

Web Deployment

No

Yes

Third-Party Support

Yes (huge)

Yes (growing)

Document-View

Yes

No

Document Management

Yes

No

Shell Integration

Yes

Yes (via installer)

Command Unification

Yes

No

UI Updating

Yes

No

Command Routing

Yes

No

Source Code

Yes

No

Managed Environment

No

Yes

The Differences

Even the features shared by MFC and WinForms/.NET are often implemented differently in the two worlds , so the following is a short discussion of each of the features.

Application Wizards

VS.NET 2003 provides MFC wizards to build applications, DLLs, COM controls, and Internet Server API (ISAPI) extensions. VS.NET 2003 provides WinForms wizards to build applications and controls for each of the four languages that are supported (C#, VB.NET, C++, and J#). VS.NET also gives you wizards for producing class library and ASP.NET server-side applications and libraries. Chapter 1: Hello, Windows Forms and Chapter 8: Controls discuss the WinForms wizards.

IDE Integration

VS.NET provides direct IDE integration for developing MFC and WinForms applications and controls. The WinForms integration is more extensive , mainly because of the strong UI layout environment and data binding, which are discussed as appropriate throughout the book.

Dialog, SDI, and MDI Applications

Both MFC and WinForms provide complete support for dialog-based, Single Document Interface (SDI), and Multiple Document Interface (MDI) applications. However, although MFC comes with a wizard that provides a great deal of functionality to help you get started when you're building SDI and MDI applications, all the WinForms wizards produce empty forms , which can serve as dialogs or MFC-style view windows depending on how they're used. This means that you must add all the standard UI and features every time you need an SDI or MDI application in WinForms. Except for the document management features, most of the body of this book is about how to develop applications that include the kinds of features you'd expect to find in an MFC application, with the specifics of MDI applications in Chapter 2: Forms.

Multi-SDI Applications

Multi-SDI applications ” applications that have a single instance but multiple top-level windows ”are fully supported in MFC. Although WinForms doesn't come out of the box supporting multi-MDI applications, Chapter 11: Applications and Settings fully explains how to build them.

UI Layout

Drag-and-drop design and layout of user interface are supported in MFC only for dialogs. Normal views must be laid out in code. WinForms, on the other hand, treats all windows in a unified manner, so the same drag-and-drop Designer works for any kind of window. What kind of window it is ”modal or modeless, dialog or view ”depends on how it's used, not on how it's designed.

Something else that's a bit different in WinForms is that the UI design environment reads and writes code instead of keeping control type and position information in a separate resource file. That code is relegated to a single method, but it is definitely mixed in with the rest of the code of the window, and that is very different from the way MFC dialogs are built. Each scheme has its pros and cons, but MFC programmers will notice the difference right away (and then may let it make them unhappy before letting it grow on them).

The WinForms Designer is discussed as appropriate through the book.

Docking and Splitting

WinForms lets you dock controls to the edges of a window as well as designate a control to take up the remaining space of the window. You can attach docked controls to splitters so that as a splitter is moved, it resizes the appropriate controls. All this is available in the design environment so that you can see what the docking and splitting will look like at design time.

MFC, on the other hand, does docking and splitting in code only. The dialog editor doesn't support this feature. Also, splitting in MFC requires separate window classes, whereas in WinForms all the docked and split controls are easily accessible from within the single container. Docking and splitting are discussed in Chapter 2: Forms.

Anchoring

When a window is resized in MFC, any controls that need to change size with the size of the containing window must be resized by hand in the WM_SIZE message handler. In contrast, WinForms anchoring (combined with docking) allows a control to be resized automatically as the container resizes. Anchoring is discussed in Chapter 2: Forms.

Toolbars and the Like

MFC excels in providing not only industrial-strength window adornments (such as toolbars, status bars, and dialog bars) for building full-featured applications, but also great IDE integration for editing them and a wizard to place initial versions for you. WinForms provides the same industrial-strength controls (as discussed in Chapter 8: Controls), but its support, especially for editing toolbars, is barely adequate, and it has no wizard to get you started. Also, WinForms has no built-in support for "floating" windows, such as floating toolbars.

Printing, Preview, and Setup

Both MFC and WinForms provide similar complete support for printing, print preview, print settings, and page settings.

OLE/Active Documents

Object Linking and Embedding is a technology for exposing and consuming data and the UI from one application into another. MFC provides complete support for this technology. WinForms supports only enough OLE to host COM controls.

Active Documents, another COM-based technology, is rather like a cross between Object Linking and Embedding and controls, but it has never really gained any traction. MFC supports it, but WinForms does not.

COM Control Hosting

Both MFC and WinForms provide complete support for hosting COM controls, and both do it using wrappers that provide an API appropriate to their respective environments. Unfortunately, neither gives you seamless integration. See Chapter 2: Forms for a discussion of how WinForms hosts COM controls.

Automation

Both MFC and WinForms provide complete support for both consuming and producing COM objects for use in application automation. In addition, .NET gives you another way to access objects between processes. Called .NET Remoting, this technology can be used as a means of application automation. Chapter 11: Applications and Settings has a short example of .NET Remoting for use in communicating between instances of the same application. [4]

[4] Ingo Rammer's Advanced .NET Remoting (APress, 2002) provides complete coverage of .NET Remoting.

F1 Help

Both MFC and WinForms support integrating help into an application, although only MFC provides a wizard to get you started. The WinForms support for integrated help is discussed in Chapter 3: Dialogs.

DDX/DDV

Because MFC was developed before Microsoft's C++ compiler supported exceptions, MFC has a two-stage construction model for windows. This means that the C++ object will come into existence before the underlying OS object or any of the contained child controls. Because of this, MFC dialogs need to move data back and forth between member variables to allow clients to provide initial child control data before the child control is created, and to make the final child control data available after the child controls have been destroyed . The mechanism to make this happen is called Dynamic Data Exchange (DDX). Similarly, validating the data as it moves is called Dynamic Data Validation (DDV). Whereas DDX is necessary because of the design of the library, DDV is always necessary.

The WinForms data exchange model is different. Each Windows object is created as an object and is shown when necessary without forcing the developer to be concerned about whether or not the underlying OS handle has been created. This means that child control properties can always be accessed directly at any time during their lifetime. In other words, the DDX is handled transparently by the controls themselves , eliminating the need to think about in it WinForms.

Data validation is still necessary, of course, and is fully supported in WinForms as discussed in Chapter 3: Dialogs.

Win32 Wrappers

Because both MFC and .NET are meant as replacements for the underlying Win32 API, it makes sense that both of them have a large number of wrapper classes to hide that API. And although .NET has MFC beat by about an order of magnitude in terms of APIs wrapped, MFC has the edge in that it's much easier to access unwrapped Win32 APIs in unmanaged C++ than it is in managed code.

Data Binding

MFC has only token support for data binding. The WinForms data binding support takes its cue from Visual Basic and provides extensive data binding support and data provider integration with the IDE. Chapter 12: Data Sets and Designer Support and Chapter 13: Data Binding and Data Grids provide an introduction to this enormous topic.

Cross-Language

MFC is a class library for C++ programmers only. WinForms (and the rest of .NET) is available to Microsoft-provided languages such as Managed C++, Jscript.NET, VB.NET, and J#, as well as dozens of third-party languages (although only Managed C++, J#, C#, and Visual Basic .NET have WinForms Designer support).

Cross-Platform

MFC is supported across all versions of Windows, and is supported across some UNIX variants by third parties. WinForms is supported under the desktop versions of Windows starting with Windows 98, and the latest version Windows CE (although VS.NET 2003 is required for Windows CE support).

Cross-Bitness

MFC was originally built to support 16-bit Windows and, because of the degree of isolation from the underlying OS, made porting to 32 bits largely a recompile in many cases. Currently, WinForms is supported only under 32 bits but will certainly provide a high (and likely seamless) degree of portability when you move your code to 64 bits.

Web Deployment

MFC applications need to be installed or copied to a machine before they can be run (with the exception of executing an application from a network share). WinForms applications support this mode of deployment, of course, but they also support no-touch deployment, which allows a WinForms application to be launched via an URL, downloaded automatically, and launched without an explicit copy or install. This model, covered in depth in Chapter 15: Web Deployment, combines the richness of Windows applications with the deployment of Web applications.

Third-Party Support

MFC programmers have years ' worth of books, articles, sample code, FAQs, archives, third-party tools, and general community knowledge at their disposal. However, even though WinForms was first released in February 2002, it has already gained a lot of those assets, and the rate of acquisition is accelerating.

Document-View

MFC 2.0 introduced Document-View, a simplified version of Model-View-Controller that separates a document's data from the view of that data. This model so permeates MFC that it wasn't until relatively recent versions of the IDE that the wizards supported generating non-Document-View code. The central idea of Document-View is a good one, but the MFC specifics of document management, such as serialization and dirty bit management, made it difficult for non-document-based applications to fit the model.

WinForms went the other way. Instead of imposing an application framework model on all applications, WinForms provides only a windowing framework. However, the central idea of separating the data from the view is still a good one and needs no real support beyond what's provided by the .NET runtime itself.

Document Management

Beyond the idea of separating data from view, the major productivity enhancement of Document-View was the document management piece, including dirty bit management, file dialog management, most recently used file lists, change notification, and so on. Those enhancements are sorely missed in .NET when it comes to building document-based applications. Luckily, that support is not very hard to build, and an example is provided with this book.

The core of document management is the ability to serialize an object graph that represents an application's data. .NET provides complete support for that kind of serialization, and a brief introduction can be found in Appendix C: Serialization Basics.

Shell Integration

Another part of the document-based piece provided by MFC is the automatic registration of file extensions with the shell and the handling of file open request operations from the shell. WinForms provides direct support for neither of these operations, but both are discussed in Chapter 11: Applications and Settings. [5]

[5] You have to look closely to see the coverage of shell integration in Chapter 11: Applications and Settings, but it's there. Check out the first couple of Registry settings examples, where you'll find the core piece that you'll need to associate a document extension in the shell with your WinForms application.

Command Unification

MFC unifies interaction for multiple kinds of controls to commands that can be handled singly . For example, to the user, choosing File Open from a menu is the same as clicking on the Open File toolbar button. These activities are unified at the class and IDE level, letting the developer easily handle all ways of invoking the same command in a single spot. WinForms provides no such facility at the class or Designer level. Only manual coding can reduce the duplication (although, to be fair, it's only a couple of lines of code).

UI Updating

Another benefit of command unification in MFC is the ability to enable or disable a command as needed without the explicit need to disable a menu item or a toolbar button separately. WinForms requires that UI elements be enabled or disabled explicitly.

Command Routing

MFC supports routing commands to any interested subscriber. .NET supports this same idea with delegates, as described in Appendix B: Delegates and Events.

Source Code

MFC provides full source code that can be read and stepped through in the debugger. The .NET Framework source code is not provided and cannot be stepped through in the debugger. Reading the source code for the .NET Framework requires a disassembler tool and a lot of patience.

Managed Environment

MFC is an unmanaged environment in the sense that memory and security must be managed by the developer explicitly. The .NET runtime provides automatic handling of both memory and security, making .NET a managed environment. A managed environment can sometimes cause a degradation in performance (although it's surprising how rare that is), but it always results in a more robust application, especially given how hard it is to track down and deal with memory and security problems. My experience is that even given a lack of some application framework features, I'm much more productive in .NET than I ever was in C++ or MFC.

Strategy

If you're moving from MFC as a programmer, this book will help you understand the new WinForms model, especially as focused by the discussion so far in this appendix. The basics are similar, so a typical MFC programmer won't have much difficulty picking up WinForms. However, WinForms is only a piece. I recommend spending some time with the C# language itself as well as the rest of the .NET Framework to fill in what you're going to need outside of WinForms.

If you're moving MFC code to .NET, you need some careful planning. Here are some considerations:

  • If you can afford to start over from scratch, that will yield the most maintainable code base, but it will take the longest.

  • If the bulk of your MFC code is in COM controls (or can be moved to COM controls), then you can use WinForms as a host for those controls and write new code in .NET.

  • If you need to bring the MFC application itself forward, you can flip the Use Managed Extensions bit on your MFC project and gain the ability to host WinForms controls [6] from your MFC 7.1 code. This also lets you write new code in .NET.

    [6] For a discussion of how to host WinForms controls as COM controls in an MFC application, see "Windows Forms: .NET Framework 1.1 Provides Expanded Namespace, Security, and Language Support for Your Projects," Chris Sells, MSDN Magazine , March 2003.

  • If the new code you'd like to integrate into your existing MFC code is not a control, you can use COM to interoperate with the .NET code while still keeping your MFC code unmanaged.

Which options apply to you depend on your specific circumstances, but in general, I recommend a strategy that lets you write the bulk of your new code in .NET, even if it means building some of the features for WinForms that you're missing from MFC.



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