Chapter 5: Recommendations for Windows Forms and "Longhorn"
Preface
Chapter 1: The "Longhorn" Opportunity
Chapter 2: Preparing for "Longhorn"
Chapter 3: Recommendations for Managed and Unmanaged Code Interoperability
Chapter 4: Recommendations for Win32, ActiveX, and "Longhorn"
Chapter 5: Recommendations for Windows Forms and "Longhorn"
Karsten Januszewski
Microsoft Corporation
February 2004
Sample updated June 2004
Applies to:
Longhorn Community Technical Preview releases (both PDC 2003 and WinHEC 2004)
Note: The downloadable sample code is based only on the Longhorn Community Technical Preview, WinHEC 2004 Build (Build 4074)
Contents of Chapter 5
Choosing Between "Avalon" and Windows Forms
Windows Forms/"Avalon" Integration
Migrating From Windows Forms to "Avalon"
Understanding the Enhancements in "Whidbey"
Further Information and Code Samples
Download the code samples described in this chapter
"Avalon" applications and Microsoft® Windows® Forms applications share many similarities. Both are managed solutions with many of the same underpinnings governing .NET Framework-based applications. There are, however, also differences between the two application models. Understanding these similarities and differences will help you assess how to adapt an existing Windows Forms application to take advantage of the capabilities in "Longhorn."
First, it is important to note that the Windows Forms classes will continue to be a central part of the Windows client as the platform moves first to "Longhorn" and then beyond it. These classes will ship natively in "Longhorn." Developers will be able to run existing Windows Forms client applications on "Longhorn" and on the versions of the operating system that follow it. Similarly, developers will also be able to use controls and forms from both Windows Forms and the "Longhorn" UI classes ("Avalon"). Effectively, these two sets of classes will live side-by-side, and developers will be able to use either of them.
Along with their respective programming models, it is important to understand when and where to use "Avalon" and when and where to use Windows Forms. We will first discuss when to use each technology. Then, we will look at the integration points between the technologies. Lastly, we will move on to a discussion of the two respective programming models.
Choosing Between "Avalon" and Windows Forms
In situations where an application can be built exclusively to run on "Longhorn," we encourage developers to rely on the "Avalon" classes so that they can take full advantage of the platform's capabilities. Developers who must maintain a single code base for a Windows client application that can run either on earlier versions of Windows or on "Longhorn" should build their UI using Windows Forms. They should structure their applications in such a way that the "Avalon" UI-based features are available if the application is running on "Longhorn."
Developers can accomplish this by referencing these features in a DLL that is either loaded or not loaded, depending on the underlying operating system version. This way, users running earlier operating systems such as Windows XP can access the entire application through Windows Forms, while "Longhorn" users can take advantage of the added features in "Avalon."
Windows Forms/"Avalon" Integration
There are three possible approaches when using the "Avalon" UI classes and controls in a Windows Forms application:
- Continue to use Windows Forms, adding "Avalon" controls or "Avalon" windows to the Windows Forms application.
- Create an "Avalon" application and reuse the existing Windows Forms controls in the application.
- Replace the Windows Forms UI of your application with a new implementation built using "Avalon."
To support the first two cases, there is an "Avalon" control that can host Windows Forms controls and a Windows Forms control that can host "Avalon" controls. These hosting controls allow a developer to interchangeably mix Windows Forms and "Avalon" controls, either on a Windows Forms form or in an "Avalon" window.
ElementHost Control
In the scenario where you would like to add new "Avalon" functionality to a Windows Forms application, there is a Windows Forms control called ElementHost that integrates with the System.Windows execution environment to ensure that Windows Forms messages are converted into equivalent messages within System.Windows' new eventing system. For example, a mouse click as seen by Windows Forms is translated into the appropriate type of event inside of System.Windows.
The ElementHost control also manages ambient properties (these are properties that children can inherit from their parents, such as background color) between the application and the embedded control; this ensures that when the property, such as the background color or font, is changed on the current form, that these changes are also propagated to the embedded System.Windows control. The code sample, "Hosting a 'Longhorn' Control in a Windows Form," shows an example of this functionality.
Note The functionality that handles the management of properties is not part of the build of "Longhorn" available at the PDC, but will be available in a future release.
WindowsFormsHost
Just as Windows Forms applications can host System.Windows using ElementHost, System.Windows applications can use the WindowsFormsHost control, which translates user input and property notifications from the System.Windows environment into their equivalents in Windows Forms. This enables the Windows Forms control to see System.Windows mouse clicks as Windows Forms mouse clicks, and also propagates property changes such as background color that occur in the System.Windows application. You would use WindowsFormHost when you are developing a "Longhorn"-only System.Windows application, but want to use an existing Windows Forms control within your application. The code sample, "Hosting a Windows Forms Control in a 'Longhorn' Application," shows an example of this functionality.
Note The functionality that handles the management of properties is not part of the build of "Longhorn" available at the PDC, but will be available in a future release.
Migrating From Windows Forms to "Avalon"
It is important to note that a Windows Forms application will run on "Longhorn" without having to make any changes to that application because features such as ClickOnce and Application Configuration are built into "Longhorn." Consequently, Windows Forms applications will run the same or better on "Longhorn."
If an application is being considered for migration from Windows Forms to "Longhorn," there are several issues that must be considered. To undertake this migration effectively, it is important to first understand both the similarities and differences between Windows Forms and "Avalon" from a programming model perspective.
Understanding the "Avalon" Programming Model
"Avalon" uses an application model that has built-in navigational capabilities allowing you to easily move state between pages within the application. While "Avalon" supports traditional client applications as well, this navigational framework is central to the "Avalon" application model, which combines the power of the client with the familiar metaphors of browsing that are common to the Internet. Windows Forms is less suited to this type of navigational framework; developers would have to create such an infrastructure themselves within Windows Forms using multiple forms to navigate between forms and to maintain state. For more on the "Avalon" application model, see the "Longhorn" SDK documentation.
Recommendation It is recommended that you become familiar with the "Avalon" application model so as to take advantage of its built-in navigation capabilities.
Understanding Composability in "Avalon"
One of the key differences between the "Avalon" and Windows Forms programming models is the notion of composability that exists solely in "Avalon." Both Windows Forms and "Avalon" allow you to build controls out of other controls. For example, the Windows Forms UserControl control or the "Avalon" Canvas control is designed to contain other controls. However, there are limits on the number of controls that can be used at one time in Windows Forms. In addition, there are limits in Windows Forms on the depth of the control tree. "Avalon" overcomes these limitations and makes creating new controls simpler through the composition of existing controls.
For example, in Windows Forms writing a DataGrid type control is very complex because it cannot be built simply out of Label and TextBox box controls. In order to write such a control, one would have to write custom painting code. However, in "Avalon," a DataGrid control could be composed from a collection of Labels and TextBoxes. Consequently, applications that require a high degree of customized controls will find the "Avalon" programming model compelling and efficient for development.
Recommendation It is recommended that you become familiar with the composability features in "Avalon."
Understanding the "Avalon" Tree Hierarchy
While both "Avalon" and Windows Forms use the concept of a tree to manage controls and hierarchy on a page, the notion of trees differs greatly between the two. The major difference is that Windows Forms doesn't have the notion of tree operations as a separate and distinct operation, whereas the tree governs the behavior of an "Avalon" page, both in terms of layouts and of events.
A major consequence of the tree hierarchy in "Avalon" is how event bubbling works. A corollary to the "Avalon" event bubbling model is not found in Windows Forms. In "Avalon," events can bubble up to a control's parent (and to that controls parent, and so on) all the way up the tree. This allows for a much finer-grained ability to handle events, as opposed to Windows Forms where events are simply associated with a control.
Recommendation It is recommended that you become familiar with how the tree hierarchy works in "Avalon."
Understanding the Markup Feature
A significant new feature in "Avalon" is the ability to declaratively design the UI using a markup syntax that is currently code-named "XAML." "XAML" provides a high-level syntax that can invoke the .NET Framework and also enables designers to create the front end of an application using familiar markup syntax. Developers can then use a procedural .NET Framework language, such as C# or VB .NET, to write code that performs the business logic of the application.
Because "XAML" is a generic mechanism for describing managed objects, it can be used to describe an "Avalon" application UI, a Windows Forms application UI, or a page that mixes both "Avalon" and Windows Forms controls. This means that, on "Longhorn," you will be able to build Windows Forms and "Avalon" applications using "XAML." The code sample, "Creating a Windows Forms UI in Markup," shows an example of this functionality.
Threading and Asynchronous Programming
The threading model is quite similar in Windows Forms and in "Avalon." As in Windows Forms, every UI control in "Avalon" has a context. The thread that created the control has access to that context. Any other thread can acquire the context. In "Avalon," acquiring that context is performed through the Context.Enter() method. If an attempt is made to call a control on a different thread before calling Context.Enter(), a thread exception will be raised. This entire threading model is very similar to using the Control.Invoke() command in Windows Forms.
Understanding the Enhancements in "Whidbey"
The next version of Microsoft Visual Studio® code-named "Whidbey" contains a number of improvements that apply to both Windows Forms and to "Avalon." These include new configuration APIs, better ways of deploying applications, an improved security model, and an improved model for asynchronous programming. These are discussed below.
The Configuration APIs
The new configuration APIs in "Whidbey" extend the configuration model in Windows Forms. The model today uses the read-only app.config technique to supply settings to the application. The new APIs will provide read/write access to configuration settings in a nested, hierarchical manner, similar to ASP.NET configuration inheritance. These new configuration APIs will be the same as those used for configuration in the "Avalon" application model.
Recommendation The recommendation moving forward is to use the new "Whidbey" configuration APIs to achieve the greatest parity with what is coming in "Longhorn."
Deploying Applications
With "Whidbey," the ClickOnce feature is available for deploying Windows Forms applications. This feature allows Windows Forms applications to be deployed and securely installed from the Web. Moreover, applications deployed through ClickOnce can be auto-updated when patches and upgrades are available. The ClickOnce feature also exists in "Longhorn" and has been enhanced with new features such as Background Intelligent Transfer Service (BITS) integration and deeper integration with the Windows shell.
Recommendation The recommendation moving forward is to start using the "Whidbey" ClickOnce feature to be prepared for deploying applications in "Longhorn."
Understanding Security
Both "Whidbey" and "Longhorn" use the notion of a restricted permission set within which an application can run based on code access security in the .NET framework. By default, in "Whidbey," the restricted permission sets are associated with Internet and intranet zones. In "Longhorn," this concept is extended to include applications running on the local machine. This restricted permission set in "Longhorn" is currently known as the Secure Execution Environment (SEE). The SEE is a natural progression of the work begun in the .Net Framework 1.0 to advance trustworthy computing. In "Longhorn," users will be able to run applications on their local machine knowing that they have limited access to sensitive local resources. The design considerations for SEE applications are the same as those for applications developed in "Whidbey" that are designed for ClickOnce applications.
Note The recommendation is to be aware of the permissions under which applications run in "Whidbey" and to be conscious of writing applications so that they run with partial trust. If an application requires privileges beyond the SEE, it doesn't need to request full trust. It can (and should) request the minimum permission set it needs to run.
Asynchronous Programming
A new model is being introduced in "Whidbey" for Windows Forms for the asynchronous programming of clients that are talking to a server. This new model improves upon the current asynchronous Web service programming model by being truly event-based. Asynchronous Web service calls will fire events that, upon completion, can be handled like any other event, on the same thread, without the developer having to handle the correlation of different threads. Fundamentally, the completion event of a Web service will behave similarly to UI events such as mouse clicks. This eventing model will be available to both Windows Forms and "Avalon" clients for making asynchronous Web service calls for data binding and communicating with a server. See the "Whidbey" SDK documentation for more information.
Further Information and Code Samples
For further guidance on specific scenarios, there are code samples that provide actual implementations. These samples include:
Hosting a Windows Forms Control in an "Avalon" Application. This sample demonstrates how "Avalon" classes and Windows Forms classes can be used together and described in "XAML" markup with code-behind files. Specifically, it illustrates the use of the WindowsFormsHost element to host a custom Windows Forms control from "Avalon" code.
Hosting an "Avalon" Control in a Windows Forms Application. This sample demonstrates how a Windows Forms application can host an "Avalon" class. Specifically, it illustrates the use of the ElementHost class to host a Frame element from within a Windows Forms application. A simple "XAML" file (test.xaml) is included in the project directory. The frame's SourceUri property is directed to this file to show that the frame is fully functional.
Creating a Windows Forms UI with "XAML." This sample demonstrates how to create a Windows Forms application using markup. The markup syntax mixes Windows Forms and "Avalon," providing a powerful way to declaratively interoperate between Windows Forms and "Avalon."
Note The Creating a Windows Forms UI with "XAML" sample is not available on the Longhorn Community Technical Preview, WinHEC 2004 Build (Build 4074).