INTRODUCTION TO THE WPF Section3
The section focuses on:
- WPF architecture.
- WPF design principles.
- The core subsystems of WPF.
- The general development process for a WPF application.
- Resources for best practices for creating WPF applications.
WPF ARCHITECTURE
WPF provides a very rich and highly integrated UI stack, exposed through a .NET programming model. Figure 1 illustrates the overall architecture and the key components of WPF.
FIGURE 1: ARCHITECTURE AND KEY COMPONENTS OF WPF
The new platform and new tools lead to improved application development workflow, and offer increased productivity, improved ability to implement an application design, and faster time to market.
WPF DESIGN PRINCIPLES
The basic design principles of WPF can be categorizes as follows:
- Integration. WPF provides a unified programming model that is consistent across controls, graphics, text, and media services, and that enables seamless integration of these elements within a single application. The WPF content model enables any control to host any group of other controls. To help arrange the content either in fixed or flow layout, WPF provides container elements that implement various layout algorithms in a way that is completely independent of the content that they are holding. Furthermore, data binding, templates, triggers, and animation provide visualized content and bring the UIs to life, giving users immediate feedback as they interact with the UI.
- Vector graphics. WPF takes full advantage of the powerful graphical processing units (GPUs) that are part of modern PC systems. At its heart, the composition engine is vector-based, enabling WPF to scale all output to match the resolution of a specific output device. In situations where hardware rendering cannot be used, software rendering is available as a fallback. In addition, a floating-point logical pixel system and 32-bit ARGB color support provide a rich, high-fidelity visual experience that anticipates future technology needs, such as high-DPI displays.
- Declarative programming. WPF introduces XAML (eXtensible Application Markup Language), an XML-based language for instantiating and populating nested object hierarchies. The design of XAML enables applications to parse and manipulate UI elements at run time. The XAML/code-behind model is supported both by the designer tool Expression Studio and the developer tool Visual Studio, which enable designers and developers to work collaboratively on application design and development.
- Easy deployment. With ClickOnce for deployment and with support for both standalone applications and browser-hosted applications, WPF offers the best of both deployment models.
MAJOR SUBSYSTEMS OF WPF
WPF is structured by using subsystems or classes that are defined in different namespaces. These classes have a very deep inheritance hierarchy. Figure 2 shows these important classes and their relationships.
FIGURE 2: CLASSES THAT MAKE UP WPF SUBSYSTEMS
The following list describes the classes that make up the WPF subsystems (links lead to documentation on the MSDN Web site for the individual class):
- Object. The base class for all .NET Framework classes.
- DispatcherObject. The base class that handles messages from other objects.
- DependencyObject (DO). The base class for any object that can support dependency properties (DPs). This class defines the
GetValue and SetValue methods that are central to the operation of DPs. - Freezable. The base class for objects that have a modifiable state and can be “frozen” into a read-only state for performance purposes.
- Visual. The base class for all objects that have their own visual representation. This class provides a tree of visual objects, each optionally containing drawing instructions and metadata about how to render those instructions, such as clipping, transformation, and so on.
Visual is the entry point to the WPF composition system. It is also the point of connection between two subsystems, the managed API and the unmanaged milcore (the core of the WPF rendering system). - UIElement. The base class for all visual objects, which provides support for layout, input, focus, and routed events (collectively referred to as LIFE).
- ContentElement. A base class that is similar to
UIElement, but for content that does not have its own rendering behavior. In order to be rendered in the UI, ContentElement objects must be hosted in an object that derives from Visual. - FrameworkElement. A base class that adds support for styles, data binding, resources, and a few common mechanisms for Windows-based controls such as tooltips and shortcut menus.
- Control. The base class that provides basic elements for GUI development, such as
Button, ListBox, and so on. The controls separate the data model (properties), interaction model (commands and events), and display model (templates), which enables developers to completely replace their visual aspect. - Shape. The base class for shape elements, such as
Ellipse, Polygon, and Rectangle. - Panel. base class for all
Panel elements, which is used to position and arrange child objects in WPF applications. - ContentControl. The base class for controls that can have only one child element. This child element can be anything from a string to a layout panel with a combination of other controls and shapes.
- ItemsControl. The base class for controls that can be used to present a collection of items, such as the
ListBox and TreeView controls. - The following table summarizes the most important of these core classes in WPF and their basic functionalities:
STEPS FOR IMPLEMENTING UI AUTOMATION
The following table lists the steps that are required in order to implement UI Automation in a WPF application.
Steps in implementing UI Automation in a WPF application
| Step | Description |
| Add UI Automation references | You must add the following UI Automation DLLs: - UIAutomationClient.dll. Provides access to the UI Automation client APIs.
- UIAutomationClientSideProvider.dll. Provides the ability to automate Win32 controls and to automate the WPF controls that interact with Win32 features. For more information, see UI Automation Support for Standard Controls.
- UIAutomationTypes.dll. Provides access to the types that are defined in UI Automation.
|
| Add the System.Windows.Automation namespace | This namespace contains everything that UI Automation clients need in order to use the capabilities of UI Automation, except text handling. |
| Add the System.Windows.Automation.Text namespace | This namespace contains everything that UI Automation clients need in order to use the text-handling capabilities of UI Automation. |
| Find controls of interest | Automated test scripts locate UI Automation elements that represent controls in the Automation tree. You can reference UI Automation elements in code in the following ways: - Query the UI by using a Condition statement. This is typically where the language-neutral AutomationId value is used.
Note: You can obtain an AutomationIdProperty value by using a tool such as UI Spy UI Spy(UISpy.exe) that can itemize the UI Automation properties of a control. - Use the TreeWalker class to traverse the whole UI Automation tree or a subset of it.
- Track focus.
- Use screen location, such as the location of the pointer.
For more information, see Obtaining UI Automation Elements on the MSDN Web site. |
| Obtain control patterns | Control patterns expose common behaviors for functionally similar controls. After automated test scripts locate the controls that require testing, they obtain the control patterns of interest from those controls, such as the InvokePattern control pattern for typical button functionality or the WindowPattern control pattern for window functionality. For more information, see UI Automation Control Patterns Overview on the MSDN Web site. |
| Automate the UI | After the control pattern has been obtained, automated test scripts can control any UI from a UI framework by using the information and functionality that is exposed by the UI Automation control patterns. |
BEST PRACTICES FOR OBTAINING UI AUTOMATION ELEMENTS
The following are best practices for obtaining UI Automation elements:
- As a rule, obtain only direct children of the RootElement object. A search for descendants might iterate through hundreds or even thousands of elements, possibly causing a stack overflow. If you are trying to obtain a specific element at a lower level, you should start your search from the application window or from a container at a lower level.
- To find a known element (identified by its Name property, AutomationId property, or other property or combination of properties), it is easiest to use the FindFirst method. If the element to find is an application window, the starting point of the search can be the RootElement object.
- To find all elements that meet specific criteria that are related to a known element, use the FindAll method. For example, you can use this method to retrieve list items or menu items from a list or menu, or to identify all controls in a dialog box.
- If you have no prior knowledge of the applications that your client might be used with, you can construct a subtree of all elements that you are looking for by using the TreeWalker class. Your application might do this in response to a focus-changed event. That is, when an application or control receives input focus, the UI Automation client examines children and perhaps all descendants of the element that has received the focus.
- After you find the supported patterns for a given UI element, we strongly recommend that you do not call
GetSupportedPatterns. Performance can be severely affected because this method calls GetCurrentPattern internally for each existing control pattern. If you can, call GetCurrentPattern only for the patterns that you need.
WAYS OF FINDING UI ELEMENTS BY USING UI AUTOMATION
Developers and testers can use the following ways to find an element by using UI Automation:
- Search for an element's AutomationId value. Note that the AutomationId value could be reused in the descendants. For more information, see Use the AutomationID property on the MSDN Web site.
- Search based on the localized control name.
- Search based on a control type.
- Search based on a PropertyCondition value.
- Obtain a control reference in an event handler.
- Search a ListItem object.
- Search based on a ClassName property value.
- In a multi-threaded apartment (MTA) application, create a single-threaded apartment (STA) thread for accessing UI that might appear broken.
- Use the WPF Dispatcher object to automate the AutomationElement object on the UI thread
If your client application might attempt to find elements in its own user interface, developers and testers must make all UI Automation calls on a separate thread. For more information, see UI Automation Threading Issues.
THREAT MODELING
Threat modeling examines a feature to determine what security threats the feature faces, and lists how these threats can be mitigated. A development team must create a threat model for areas that might have security implications. Testers must understand the threat model, attempt to devise threats that are not listed in the threat model, and test that all described security mitigations are in place.
When testing partially trusted .NET Framework applications, such as .xbap applications, testers must follow these guidelines:
- Avoid using workarounds to obtain full-trust behavior from inside an .xbap application. A common way to implement this workaround is to put a fully-trusted assembly in the global assembly cache(GAC), and to have this assembly perform elevated-trust operations. This is not a realistic customer scenario and should be avoided unless the elevated operations being performed are unrelated to the scenarios being tested.
- When running tests on Windows Vista, pay attention to the elevation level of the process. Security-related (and other) bugs might be hidden when a tester runs a test from an elevated-privilege process. When possible, testers should execute applicable scenarios both as restricted and as elevated processes on Windows Vista.
ELECTING A CLASS TO DERIVE FROM
WPF provides three models for creating a control, each with different features and levels of flexibility. Make sure that you understand these models before you write a new control. The following table lists the models and characteristics of each.
| Model | Characteristics |
| Derive from UserControl | Pros: Supports rich content, styles, and triggers. Cons: Does not support templates and themes; not customizable. When to use: - Your control consists only of existing components.
- You do not have to support complex customization.
|
| Derive from Control. This is the model that is used by most of the built-in WPF controls. | Pros: Designed to separate the operational logic from the visual representation by using templates and themes, and therefore provides the most flexibility. Cons: More complex comparing to building a class derived from UserControl. When to use: - You want the appearance of your control to be customizable by using the
ControlTemplate class. - You want your control to support different themes.
|
| Derive from FrameworkElement. | Pros: Most flexible. Better performance if you do not have to have the templating mechanism. Cons: Can be more complex than other models. When to use: - You do not want to use teamplate for your control; instead, you want to handle the visual children creation and hookup.
- You want more fine-grained control over functionality than what you have when you derive from
UserControl or Control (which rely on composing existing elements).
There are two standard methods for building this kind of control: direct rendering and custom element composition. Direct rendering involves overriding the OnRender method of FrameworkElement and providing DrawingContext operations that explicitly define the component visuals. Custom element composition involves instantiating and using objects of type Visual to compose the appearance of your component. |
ADDITIONAL CONSIDERATIONS
The following list provides additional points to be considered when a custom control is created.
- How should I package the control?
- When should I use DependencyProperty objects instead of CLR properties?
- When should I use RoutedEvent objects instead of CLR events?
- When I should I use Command objects?
- How do I create templates for the control and what is the performance cost? What are the ways I can reduce the performance costs?
- How do I author theme-based styles and templates for the control?
- How should I package themed resources?
- How do I make the control accessible?
- How do I make the control localizable?
- How do I add design-time support to the control?
- How do I build a design experience for the control in Microsoft Expression Blend and Microsoft Visual Studio?
- How do I support journaling for the control's properties?
- How can I virtualize the UI pieces in the control (if applicable)?
- How can I support data virtualization for the control?
BEST PRACTICES FOR CUSTOM CONTROL AUTHORING
The following list describes best practices to follow when a custom control is created.
- Make sure that you understand the three general models for control creation before you commit to a model for your new control.
- To make a control easy to reuse, package it into its own assembly.
- Generally, it is a good practice to back all the properties in your new control with a DependencyProperty object. For more information, see Custom Dependency Properties on the MSDN Web site.
- Just as dependency properties extend CLR properties with additional functionality, routed events extend standard CLR events. When you create a new WPF control, it is a good practice to implement your events as RoutedEvent objects. For more information, see Routed Events Overview and How to: Create a Custom Routed Event on the MSDN Web site.
- To decouple the UI of the control from its logic, consider using data binding. This is especially important if you define the appearance of your control by using a ControlTemplate class.
To add support for custom WPF controls in the WPF Designer for Visual Studio, follow these guidelines:
- For DependencyProperty objects, implement CLR get accessor for read-only properties.
- For AttachedProperty objects, do the following:
- Create a public static read-only DependencyProperty instance of the form PropertyNameProperty that you create by using the RegisterAttached method.
- Implement a pair of public static CLR methods named GetPropertyName (for all properties) and SetPropertyName (for read/write properties). These methods must route directly to the GetValue and SetValue methods of the target dependency object.
- Use a Command object, which is a more flexible way to handle input (events, etc.) than without using it. For more information about commands, see Commanding Overview.
- Consider creating a theme assembly that contains resource dictionaries that override the default styles. To do this, create multiple ResourceDictionary files, by using the naming convention of Theme Name.Theme Color.xaml (for example, Luna.NormalColor.xaml). Put the files in the directory named Themes. Make sure that you include a Generic.xaml file to serve as a fallback style.
SECURITY CONSIDERATIONS
Automation peers must work in a partial-trust environment. Because the UIAutomationClient assembly is not configured to run under partial trust, your provider code (the custom control code) should not reference that assembly. If it does so, the code might run in a full-trust environment but then fail in a partial-trust environment. In particular, do not use fields from classes in UIAutomationClient such as those in AutomationElement. Instead, use the equivalent fields from classes in the UIAutomationTypes assembly, such as AutomationElementIdentifiers.
ADDITIONAL RESOURCES FOR CUSTOM CONTROL AUTHORING
For more information about custom control authoring, see the following resources on the MSDN Web site:
CUSTOM CONTROL AUTHORING WITH AUTOMATION PEERS
To create a custom control with Automation support, follow the steps listed in the following table.
| Functionality | Implementation |
| Expose the control to UI Automation | Override the OnCreateAutomationPeer method for the custom control so that it returns your provider object, which must derive directly or indirectly from AutomationPeer. For example, if a custom control that is derived from Button is named MyButton, the object returned by OnCreateAutomationPeer should be MyButtonAutomationPeer. |
| Provide property values | Override the methods of the base peer class that get property values of the control (for example, AutomationPeer.GetAcceleratorKey) and of any additional control pattern interfaces that are implemented by your custom peer (for example, IToggleProvider.ToggleState). |
| Enable the client to interact with the control | Override methods of the base peer class (for example, ToggleButtonAutomationPeer.IToggleProvider.Toggle) and of any additional control pattern interfaces that are implemented by your custom peer. In your provider's implementation of GetPattern, return the object that supports the specified control pattern. This could be the peer object, or it could be the control object that the peer object represents. |
| Raise events | Call RaiseAutomationEvent and RaisePropertyChangedEvent methods of the custom AutomationPeer class in order to raise the appropriate pattern events. For example, in a custom control's OnClick event (for example, MyButton.OnClick), make the following call: myButtonPeer.RaiseAutomationEvent(AutomationEvents.InvokePatternOnInvoked)
|
Developers should remember the following points when they create a custom control with Automation support.
- If the custom control's UI includes a collection of standard controls (for example, Button and TextBox), in the custom control's AutomationPeer class, override the base peer class's GetChildrenCore or GetChildren method in order to return the collection of the standard controls' Automation peers. If the custom control derives from UIElementAutomationPeer, by default the implementation of GetChildrenCore will walk the children in the visual tree and return the list of the children’s Automation peers. If you do not want to expose all the visual elements, you can override GetChildrenCore and return only the peers that you want.
- If the custom control contains a Popup control, do not rely on walking the visual tree, because Popup content is in a separate visual tree. For example, ComboBoxAutomationPeer.GetChildrenCore should return a list of Automation peers that correspond to the elements under the Popup control's visual tree.
- If the custom control is derived from the Control class, and the Control class does not include an AutomationPeer object itself, derive the custom peer class from FrameworkElementAutomationPeer.
- When you raise Automation events, for performance reasons make sure that the events are raised only when there are listeners on the clients. To do this, use AutomationPeer.ListenerExists to check related events.
CUSTOM CONTROL AUTHORING AND TESTING SAMPLE
A sample solution is available that you can use and examine to learn more about how to create custom controls and about how to test them. To obtain the sample, download the compressed file that contains the sample from the WPF Testing blog.
The sample solution contains the following projects:
- A custom control library that includes two custom controls, both with UI Automation support built in.
- A WPF application that uses the custom controls.
- A test project to drive the WPF application by using UI Automation APIs.
- A second test project that shows how to embed test code in the application that is being tested.
For more samples that show how to create WPF custom controls, see Control Customization Samples on the MSDN Web site.
TESTING WPF CUSTOM CONTROLS WITH UI AUTOMATION PEERS
When you test WPF custom controls with UI Automation peers, follow these guidelines:
- Make sure that the custom control supports UI Automation with
AutomationPeer. For more information, see the sample solution described in the section Custom Control Authoring and Testing Sample. - Follow the best practices described in the section Basic Guidelines for Making UI Available in order to make sure that controls are properly labeled.
- For informaiton about how to unit-test a custom control, examine the example described in the blog entry Unit Testing WPF controls with Automation Peers. The example shows how to test a standard control. The steps are the same for the custom control, except that you use the custom control's
AutomationPeer object for testing. - To test the custom control as part of an application's UI Automation testing process, see the sample solution described in the section Custom Control Authoring and Testing Sample.
- Make sure that support in the control for different themes is validated.
TOOLS
This section provides a preliminary list of the tools available for creating, debugging, profiling, and testing WPF applications. In the current release of the paper, we list tools for performance profiling. Other tools will be covered in future editions.
UI AUTOMATION TOOLS
The following list provides information about UI automation tools.
- UI Spy (UISpy.exe) is a graphical user interface (GUI) application that can be used to gather UI Automation information for both provider and client development and debugging. UI Spy is included in the Windows Software Development Kit (SDK).
UIAutoCmd is a command-line tool with capabilities similar to those of UI Spy.- UI Automation Verify (UIA Verify) Test Automation Framework - UIA Verify is a test automation framework that features the User Interface Automation Test Library (UIA Test Library) and Visual UI Automation Verify (Visual UIA Verify), a graphical user interface tool.
- UI Accessibility Checker (or AccChecker) is a tool that enables testers without prior experience in accessibility to easily discover potential problems with Microsoft Active Accessibility (MSAA) and to discover other accessibility problems in UI implementations.
MSAABridge exposes UI Automation information to Active Accessibility clients. The primary goal of bridging UI Automation to Active Accessibility is to provide existing Active Accessibility clients the ability to interact with any framework that has implemented UI Automation.NUnit in conjunction with UI Automation Framework can be used to perform unit test of WPF controls.- White UI Test framework - an open source extension for the NUnit open source test framework. The tool uses the System.Windows.Automation namespace to access UI pages and controls for test purposes. It can support testing Win32, Win Form, WPF and SWT (java) applications”.
The following list provides information about shows some third-party UI Automation testing tools that are often used outside Microsoft:
- TestComplete. This tool has XAML/WPF application testing support.
DEBUGGING TOOLS
The following list provides information about debugging tools for WPF.
- Snoop. This is a WPF application debugging utility that simplifies visual debugging of WPF applications.
- Visual Studio Visualizer for WPF (Mole). This is another WPF debugging and visualization tool from the WPF community.
PERFORMANCE PROFILING TOOLS
The following list provides information about performance-profiling tools for WPF.
- Event Trace. Use this tool for analyzing events and generating event log files.
- Perforator. This tool is used for analyzing rendering behavior.
- ETW Trace Viewer. This tool can record, display, and browse Event Tracing for Windows (ETW) log files in a WPF user-interface format.
- Visual Profiler. This tool profiles the use of WPF services by elements in the visual tree, such as layout and event handling.
- Working Set Analyzer. This tool analyzes the working-set characteristics of an application.
WPF APPLICATION DESIGN AND DEVELOPMENT TOOLS
The following table provides information about several tools for creating WPF applications: Expression Design, Expression Blend, and Visual Studio 2008. The table lists the areas of WPF for which they provide support.
|
| Expression Design | Expression Blend | Visual Studio 2008 |
| Layout | Static, absolute positioned | Dynamic | Dynamic |
| Styling | No | Visual Editor | No |
| Layout | Static, absolute positioned | Dynamic | Dynamic |
| Templating | No | Visual Editor | No |
| Resources | As export option | Visual Editor | No |
| Code support | No | Basic Editor | Rich IntelliSense |
| XAML roundtrips | One-way | Yes | Yes |
| XAML exporting | Limits capabilities early to prevent lossiness | Yes | Yes |
| Animation | No | Visual editor | XAML editor only |
The following list provides information about additional tools for creating WPF applications.
- XAMLPad. This is a basic visual editor for Extensible Application Markup Language (XAML).
- ZAM 3D by Electric Rain. This tool provides developers and designers with a quick and easy solution for creating 3D interface elements for WPF-based applications. It also provides a 3Ds-to-XAML and dxf-to-XAML converter.
The Multi-platform Advantage
The first thing to keep in mind is that the platforms are not mutually exclusive. WPF and Windows Forms can both be used in a single application since each technology is capable of hosting user interface elements defined by the other. The two platforms have different strengths and can complement each other. For example, Windows Forms provides many useful LOB controls, while WPF uniquely offers things such as 3D graphics and animations.
Current Windows Forms-based projects can start using the benefits of WPF gradually and incrementally. Windows Forms and WPF interoperability make it easy to extend existing projects. Some early adopters have piloted this by building a new WPF visualization or component for their existing application using the interoperability layer.
Similarly, WPF can also be used in concert with MFC or Win32. WPF controls can be hosted within existing Win32/MFC code, and existing Win32/MFC controls can be hosted within WPF. Microsoft Expression Design is an example of a project that mixed Win32 code with WPF to provide an improved user experience without rewriting the entire application. This is a real world example of how using WPF doesn’t require throwing away all of an application’s existing code.
The Benefits of Windows Forms
Window Forms is a mature "forms over data" technology. It has an extensive ecosystem of controls, developers, and vendors that has evolved over the last twenty years of development based on the GDI/GDI32/GDI+ platform. These are good reasons to continue using Windows Forms.
There are also some features that are unique to this platform. Windows Forms has a wide range of controls for presenting tabular data, for working with system dialogs, for graphics metafiles, and for date, time and calendar support. The richest design surface in Visual Studio is for Windows Forms, allowing rapid construction of an LOB application. It provides extensive support to quickly build databound applications and to connect to remote data sources.
Microsoft has announced the continued support of Windows Forms so if you have an existing Windows Forms application you can feel secure in a good level of support for your existing code base. Developers with years of experience with Windows Forms can continue to be productive working in a technology they are familiar with. If you need to deploy on older PCs running versions of Windows prior to XP SP2, Windows Forms will work well under these conditions.
If you are building a traditional forms-based application, have existing expertise in Windows Forms, and are satisfied with current tools and components then Windows Forms continues to be a good fit. It leverages Microsoft’s ongoing investment in .NET (such as LINQ and the Dynamic Language Runtime) and provides a robust set of controls and best of breed IDE and forms designer in Visual Studio. Since Microsoft will support Windows Forms for many years, the main reason to look at Windows Presentation Foundations is if you’re ready to take advantage of its unique features.
The Benefits of Windows Presentation Foundation
Windows Presentation Foundation was created to allow developers to easily build the types of rich applications that were difficult or impossible to build in Windows Forms, the type that required a range of other technologies which were often hard to integrate. For example, the medical application below combines 2D & 3D graphics with re-styled forms element and interactive visualizations allowing the user to better understand and evaluate their data :
WPF is the platform of choice for today’s visually demanding applications with its inherent support of rich media, data visualization, complex text content, dynamic interactive experiences, and branded or custom look and feel. For these types of applications, WPF provides significant advancements in areas such as advanced layout, control skinning and styling, animated hardware accelerated 2D and 3D graphics, and built in support for rendering of rich documents.
The examples below show applications which have been built using WPF to enable new types of user experiences:
WPF shipped with approximately thirty controls including creative controls such as the InkCanvas and the Grid control. Additional controls will be delivered for WPF in 2008. There are also third-party controls available already for the platform. Since the platform is new, so is the tooling. Visual Studio 2008 has core WPF support with a new design surface that provides drag and drop support for WPF layout and controls, a new property editor, as well as Intellisense support for XAML editing. Moving forward, Microsoft is committed to extending the support for WPF even further in the next version of Visual Studio. The type of richer applications that WPF enables generally requires the participation of new team members: visual and interaction designers. Because of this, Microsoft has introduced a new tool for these roles—Microsoft Expression Blend. This product focuses on the more creative, visual, and interactive aspects of the platform by exposing WYSIWYG ways to manipulate animation, skinning and styling, databinding, and general visual asset creation. To help integrate these team members, Expression Blend supports Visual Studio projects.
A less obvious advantage to WPF is the improved development experience with its declarative markup language (XAML) that can be used for bulk of many applications. WPF makes it easier to follow the model-view-presenter pattern and reduces the amount of code in your presenter using templates. The benefits of XAML are not just in the presentation, databinding allows declarative connection to the underlying model. All of this makes it much easier to change your user interface without needing to change the other layers of your application. Another important aspect of XAML is the ability through these file formats to have designers and developers able to work on the same files .
A last advantage worth mentioning is that Silverlight will maintain a high level of compatibility with WPF so investments in WPF allow for easy porting and sharing between Web and Windows client applications. If you are considering the need to deploy to other platforms then you will be able to make use of Silverlight with almost the same code as WPF.
Going forward, Windows Presentation Foundation will be Microsoft’s solution for most types of applications including standard forms-based applications. WPF is a foundation which goes beyond traditional platforms and other user interface toolkits. The potential with the WPF platform is to build applications that set a new bar for sophistication, usability and user experience.
Conclusions
In conclusion:
- If you have an existing Windows Forms application or are building a traditional forms-based application and are looking for a mature technology to use with mature tools and component support then Windows Forms is a good fit.
- If you have an existing Windows Forms (or MFC/Win32) application that could benefit from some of the advanced presentation features of WPF, you can add WPF to your existing project.
- If you’re wanting to create a new experience for your users that is rich, interactive, sophisticated, or highly custom or branded, WPF is Microsoft’s next-generation platform for your project today.
- If you’re targeting the web, Silverlight shares the same development model as WPF but is optimized for a lightweight, cross-platform runtime. Investing in either WPF or Silverlight nets you the skills, tools, and assets for both platforms.
With all of these choices, you can be assured that all of these platforms will be supported for years to come.
