MFC Versus Windows Forms
| Some folks do need to build document-based applications, and even though Windows Forms 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 Windows Forms does and doesn't provide as compared with MFC. Table B.1 shows a feature-based summary focused on building document-based applications.
The DifferencesThe features shared by MFC and Windows Forms/.NET are often implemented differently in the two worlds, so the following is a short discussion of each of the features. Application WizardsVS05 provides MFC wizards to build applications, DLLs, COM controls, and Internet Server API (ISAPI) extensions. VS05 provides Windows Forms wizards to build applications and controls for each of the four languages that are supported (C#, VB.NET, C++, and J#). VS05 also gives you wizards (called "project templates") for producing class library and ASP.NET server-side applications and libraries. Although this book is littered with discussions of the Windows Forms project templates, Chapter 1: Hello, Windows Forms, Chapter 10: Controls, and Chapter 14: Applications are good places to start. IDE IntegrationVS05 provides direct IDE integration for developing MFC and Windows Forms applications and controls. The Windows Forms integration is more extensive, mainly because of the strong UI layout environment and data binding, which are discussed throughout this book. Dialog, SDI, and MDI ApplicationsBoth MFC and Windows Forms provide complete support for dialog-based, SDI, and 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, most of the Windows Forms wizards produce empty forms, which can serve as dialogs or MFC-style view windows depending on how they're used. This means that, in most cases, you must add the standard UI and all the features every time you need an SDI application in Windows Forms, although you can use the MDI Parent Form project item template to get a head start on MDI applications, as discussed in Chapter 2: Forms. 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, including document management features (see Appendix F: Document Management, with the specifics of MDI applications covered in Chapter 2 and Chapter 14). Multiple-SDI ApplicationsMultiple-SDI applicationsapplications that have a single instance but multiple top-level windowsare fully supported in MFC. Although Windows Forms doesn't come with a complete out-of-the-box solution to support multiple-SDI applications, Chapter 14 fully explains how to leverage some .NET Framework elements to build them. UI LayoutDrag-and-drop design and layout of user interfaces are supported in MFC only for dialogs. Normal views must be laid out in code. Windows Forms, on the other hand, treats all windows in a unified manner, so the same drag-and-drop designer works for any kind of window. Which kind of window it ismodal or modeless, dialog or viewdepends on how it's used, not on how it's designed. Something else that's a bit different in Windows Forms 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 (although divided between different files). For MFC dialogs in .NET 2.0, 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 Windows Forms Designer is discussed throughout the book. Docking and SplittingWindows Forms lets you dock controls to the edges of a window as well as designate a control to take up the window's remaining space. You can dock controls within split containers 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 Windows Forms all the docked and split controls are easily accessible from within the single container. Docking and splitting are discussed in Chapter 4: Layout. AnchoringWhen 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, Windows Forms anchoring (combined with docking) allows a control to be resized automatically as the container resizes. Anchoring is discussed in Chapter 4. Tool Strips and the LikeMFC excels in providing not only industrial-strength window adornments (such as tool strips, status strips, 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. The same is true for Windows Forms with the use of its tool strip control suite, although these controls support dragging but not floating. However, the MFC tool strips are looking a little dated when compared with those found in modern applications, whereas the Windows Forms tool strips just got a major boost into the present with this release. Printing, Preview, and SetupBoth MFC and Windows Forms provide similar complete support for printing, print preview, print settings, and page settings. OLE and Active DocumentsObject 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. Windows Forms supports only enough OLE to host COM controls. Active Documents, another COM-based technology, is rather like a cross between OLE and controls, but it has never really gained any traction. MFC supports it directly, but Windows Forms does not. However, you can host the WebBrowser control and use it as an Active Document host by navigating to a file from an application (such as Microsoft Word) that provides Active Document support. COM Control HostingBoth MFC and Windows Forms 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 10 for a discussion of the way Windows Forms hosts COM controls. AutomationBoth MFC and Windows Forms 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. F1 HelpBoth MFC and Windows Forms support integrating help into an application, although only MFC provides a wizard to get you started. The Windows Forms support for integrated help is discussed in Chapter 3: Dialogs. DDX and DDVBecause 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 comes 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 Windows Forms 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 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 for developers to think about in it Windows Forms. Data validation is still necessary, of course, and is fully supported in Windows Forms as discussed in Chapter 3. Win32 WrappersBecause 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 native C++ than it is in managed code. Data BindingMFC has only token support for data binding. The Windows Forms data binding support takes its cue from Visual Basic 6 and provides extensive data binding support and data provider integration with the IDE. Chapter 16: Data Binding Basics and Chapter 17: Applied Data Binding provide an introduction to this huge topic. Cross-LanguageMFC is a class library for C++ programmers only. Windows Forms (and the rest of .NET) is available to Microsoft-provided languages such as Managed C++, Jscript.NET, Visual Basic, and J#, as well as dozens of third-party languages (although only Managed C++, J#, C#, and Visual Basic .NET have Windows Forms Designer support). Cross-PlatformMFC is supported across all versions of Windows and is supported across some UNIX variants by third parties. Windows Forms is supported under the desktop versions of Windows starting with Windows 98, and the latest version of Windows CE (although VS05 is required for Windows CE support). Cross-BitnessMFC 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. Windows Forms supports both 32 and 64 bits with no recompile necessary. Web DeploymentMFC applications must be installed or copied to a machine before they can be run (with the exception of executing an application from a network share). Windows Forms applications support this mode of deployment, of course, but they also support ClickOnce deployment, which allows a Windows Forms application to be launched via an URL, downloaded automatically, and executed without an explicit copy or install, in a trustworthy fashion. This model, covered in depth in Chapter 19: ClickOnce Deployment, combines the richness of Windows applications with the deployment of Web applications. Third-Party SupportMFC programmers have years worth of books, articles, sample code, FAQs, archives, third-party tools, and general community knowledge at their disposal, although this support has dropped dramatically since the initial release of the .NET Framework. Windows Forms has at least as much support in the community as MFC ever had, if not more. Document-ViewMFC 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 later 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 nondocument-based applications to fit the model. Windows Forms went the other way. Instead of imposing an application framework model on all applications, Windows Forms 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 ManagementBeyond 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, building that support is not very hard, and, indeed, an appendix in this book is dedicated to this topic: Appendix F: Document Management. Shell IntegrationAnother 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. Windows Forms provides direct support for neither of these operations, but both are discussed in Appendix F. Command UnificationMFC 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 tool strip 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. Windows Forms 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 UpdatingAnother 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 tool strip button separately. Windows Forms requires that UI elements be enabled or disabled explicitly. Command RoutingMFC supports routing commands to any interested subscriber. .NET supports this same idea with delegates, as described in Appendix C: Delegates and Events. Source CodeMFC 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.[4]
Managed EnvironmentMFC is a native environment in the sense that memory and security must be handled 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. StrategyIf you're moving from MFC as a programmer, this book will help you understand the new Windows Forms 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 Windows Forms. However, Windows Forms 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'll need outside Windows Forms. If you're moving MFC code to .NET, you need some careful planning. Here are some considerations:
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 Windows Forms that you're missing from MFC. |
EAN: 2147483647
Pages: 216