Language
Edit

Windows Presentation Foundation Overview

Welcome to the Desktop Guide for Windows Presentation Foundation (WPF), a UI framework that's resolution-independent and uses a vector-based rendering engine, built to take advantage of modern graphics hardware. WPF provides a comprehensive set of application-development features that include Extensible Application Markup Language (XAML), controls, data binding, layout, 2D and 3D graphics, animation, styles, templates, documents, media, text, and typography. WPF is part of .NET, so you can build applications that incorporate other elements of the .NET API.

WPF has two implementations:

  1. .NET version (this guide):

    An open-source implementation of WPF hosted on GitHub, which runs on .NET. The XAML designer requires, at a minimum, Visual Studio 2019 version 16.8. But depending on your version of .NET, you may be required to use a newer version of Visual Studio.

    Even though .NET is a cross-platform technology, WPF only runs on Windows.

  2. .NET Framework 4 version:

    .NET Framework implementation of WPF that's supported by Visual Studio 2019 and Visual Studio 2017.

    .NET Framework 4 is a Windows-only version of .NET and is considered a Windows Operating System component. This version of WPF is distributed with .NET Framework.

This overview is intended for newcomers and covers the key capabilities and concepts of WPF. To learn how to create a WPF app, see Tutorial: Create a new WPF app.

Why upgrade from .NET Framework

When you upgrade your application from .NET Framework to .NET, you benefit from:

  • Better performance
  • New .NET APIs
  • The latest language improvements
  • Improved accessibility and reliability
  • Updated tooling and more

To upgrade your application, see How to upgrade a WPF desktop app to .NET.

Program with WPF

WPF exists as a subset of .NET types that are mostly located in the System.Windows namespace. If you've previously built applications with .NET using frameworks like ASP.NET and Windows Forms, the fundamental WPF programming experience should be familiar. You:

  • Instantiate classes
  • Set properties
  • Call methods
  • Handle events

WPF includes more programming constructs that enhance properties and events: dependency properties and routed events.

Markup and code-behind

WPF lets you develop an application using both markup and code-behind, an experience with which ASP.NET developers should be familiar. You generally use XAML markup to implement the appearance of an application while using managed programming languages (code-behind) to implement its behavior. This separation of appearance and behavior has the following benefits:

  • Development and maintenance costs are reduced because appearance-specific markup isn't tightly coupled with behavior-specific code.

  • Development is more efficient because designers can implement an application's appearance simultaneously with developers who are implementing the application's behavior.

  • Globalization and localization for WPF applications is simplified.

Markup

XAML is an XML-based markup language that implements an application's appearance declaratively. You typically use it to define windows, dialog boxes, pages, and user controls, and to fill them with controls, shapes, and graphics.

The following example uses XAML to implement the appearance of a window that contains a single button:



  
  


Specifically, this XAML defines a window and a button by using the Window and Button elements. Each element is configured with attributes, such as the Window element's Title attribute to specify the window's title-bar text. At run time, WPF converts the elements and attributes that are defined in markup to instances of WPF classes. For example, the Window element is converted to an instance of the Window class whose Title property is the value of the Title attribute.

The following figure shows the user interface (UI) that is defined by the XAML in the previous example:

A window that contains a button

Since XAML is XML-based, the UI that you compose with it is assembled in a hierarchy of nested elements that's known as an element tree. The element tree provides a logical and intuitive way to create and manage UIs.

Code-behind

The main behavior of an application is to implement the functionality that responds to user interactions. For example, clicking a menu or button and calling business logic and data access logic in response. In WPF, this behavior is implemented in code that's associated with markup. This type of code is known as code-behind. The following example shows the updated markup from the previous example and the code-behind:



  
  


The updated markup defines the xmlns:x namespace and maps it to the schema that adds support for the code-behind types. The x:Class attribute associates a code-behind class to this specific XAML markup. Considering this attribute is declared on the element, the code-behind class must inherit from the Window class.

using System.Windows;

namespace SDKSample
{
    public partial class AWindow : Window
    {
        public AWindow()
        {
            // InitializeComponent call is required to merge the UI
            // that is defined in markup with this class, including  
            // setting properties and registering event handlers
            InitializeComponent();
        }

        void button_Click(object sender, RoutedEventArgs e)
        {
            // Show message box when button is clicked.
            MessageBox.Show("Hello, Windows Presentation Foundation!");
        }
    }
}
Namespace SDKSample

    Partial Public Class AWindow
        Inherits System.Windows.Window

        Public Sub New()

            ' InitializeComponent call is required to merge the UI
            ' that is defined in markup with this class, including  
            ' setting properties and registering event handlers
            InitializeComponent()

        End Sub

        Private Sub button_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)

            ' Show message box when button is clicked.
            MessageBox.Show("Hello, Windows Presentation Foundation!")

        End Sub

    End Class

End Namespace

InitializeComponent is called from the code-behind class's constructor to merge the UI that's defined in markup with the code-behind class. (InitializeComponent is generated for you when your application is built, which is why you don't need to implement it manually.) The combination of x:Class and InitializeComponent ensure that your implementation is correctly initialized whenever it's created.

Notice that in the markup the

Because this style targets all Button controls, the style is automatically applied to all the buttons in the window, as shown in the following figure:

Two orange buttons

For more information, see Styles and templates.

Resources

Controls in an application should share the same appearance, which can include anything from fonts and background colors to control templates, data templates, and styles. You can use WPF's support for user interface resources to encapsulate these resources in a single location for reuse.

The following example defines a common background color that is shared by a Button and a Label:



  
  
    
  

  
  

  
  

For more information, see How to define and reference a WPF resource.

Custom controls

Although WPF provides a host of customization support, you may encounter situations where existing WPF controls do not meet the needs of either your application or its users. This can occur when:

  • The user interface that you require cannot be created by customizing the look and feel of existing WPF implementations.
  • The behavior that you require isn't supported (or not easily supported) by existing WPF implementations.

At this point, however, you can take advantage of one of three WPF models to create a new control. Each model targets a specific scenario and requires your custom control to derive from a particular WPF base class. The three models are listed here:

  • User Control Model
    A custom control derives from UserControl and is composed of one or more other controls.

  • Control Model A custom control derives from Control and is used to build implementations that separate their behavior from their appearance using templates, much like most WPF controls. Deriving from Control allows you more freedom for creating a custom user interface than user controls, but it may require more effort.

  • Framework Element Model.
    A custom control derives from FrameworkElement when its appearance is defined by custom rendering logic (not templates).

For more information on custom controls, see Control authoring overview.

See also