WPF Tutorial Page 1 of 431
WPF Tutorial Page 1 of 431
WPF Tutorial
But what IS a GUI framework? GUI stands for Graphical User Interface, and you're probably looking at one
right now. Windows has a GUI for working with your computer, and the browser that you're likely reading
this document in has a GUI that allows you to surf the web.
A GUI framework allows you to create an application with a wide range of GUI elements, like labels,
textboxes and other well known elements. Without a GUI framework you would have to draw these
elements manually and handle all of the user interaction scenarios like text and mouse input. This is a LOT
of work, so instead, most developers will use a GUI framework which will do all the basic work and allow
the developers to focus on making great applications.
There are a lot of GUI frameworks out there, but for .NET developers, the most interesting ones are
currently WinForms and WPF. WPF is the newest, but Microsoft is still maintaining and supporting
WinForms. As you will see in the next chapter, there are quite a few differences between the two
frameworks, but their purpose is the same: To make it easy to create applications with a great GUI.
In the next chapter, we will look at the differences between WinForms and WPF.
The single most important difference between WinForms and WPF is the fact that while WinForms is simply
a layer on top of the standard Windows controls (e.g. a TextBox), WPF is built from scratch and doesn't rely
on standard Windows controls in almost all situations. This might seem like a subtle difference, but it really
isn't, which you will definitely notice if you have ever worked with a framework that depends on
Win32/WinAPI.
A great example of this is a button with an image and text on it. This is not a standard Windows control, so
WinForms doesn't offer you this possibility out of the box. Instead you will have to draw the image yourself,
implement your own button that supports images or use a 3rd party control. With WPF, a button can
contain anything because it's essentially a border with content and various states (e.g. untouched, hovered,
pressed). The WPF button is "look-less", as are most other WPF controls, which means that it can contain
a range of other controls inside of it. You want a button with an image and some text? Just put an Image
and a TextBlock control inside of the button and you're done! You simply dont get this kind of flexibility out
of the standard WinForms controls, which is why there's a big market for rather simple implementations of
controls like buttons with images and so on.
The drawback to this flexibility is that sometimes you will have to work harder to achieve something that
was very easy with WinForms, because it was created for just the scenario you need it for. At least that's
how it feels in the beginning, where you find yourself creating templates to make a ListView with an image
and some nicely aligned text, something that the WinForms ListViewItem does in a single line of code.
This was just one difference, but as you work with WPF, you will realize that it is in fact the underlying
reason for many of the other differences - WPF is simply just doing things in its own way, for better and for
worse. You're no longer constrained to doing things the Windows way, but to get this kind of flexibility, you
pay with a little more work when you're really just looking to do things the Windows way.
The following is a completely subjective list of the key advantages for WPF and WinForms. It should give
you a better idea of what you're going into.
The preferred choice for a .NET/WPF IDE is Visual Studio, which costs a lot quite a bit of money though.
Luckily, Microsoft has decided to make it easy and absolutely free for everyone to get started with .NET
and WPF, so they have created a free version of Visual Studio, called Visual Studio Express. This version
contains less functionality than the real Visual Studio, but it has everything that you need to get started
learning WPF and make real applications.
The latest version, as of writing this text, is Microsoft Visual Studio Express 2012. To create WPF
applications, you should get the Windows Desktop edition, which can be downloaded for free from this
website: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop.
After downloading and installing, you can use this product for 30 days without any registration. After that,
you will need to register it on the above mentioned website, which is also completely free.
The rest of this tutorial assumes that you have an IDE installed, preferably Visual Studio or Visual Studio
Express (see the previous article for instructions on how to get it). If you're using another product, you will
have to adapt the instructions to your product.
In Visual Studio, start by selecting New project from the File menu. On the left, you should have a tree of
categories. This tutorial will focus on C# whenever code is involved, so you should select that from the list
of templates, and since we'll be creating Windows applications, you should select Windows from the tree.
This will give you a list of possible Windows application types to the right, where you should select a WPF
Application. I named my project "HelloWPF" in the Name text field. Make sure that the rest of the settings
in the bottom part of the dialog are okay and then press the Ok button.
Your new project will have a couple of files, but we will focus on just one of them now: MainWindox.xaml.
This is the applications primary window, the one shown first when launching the application, unless you
specifically change this. The XAML code found in it (XAML is discussed in details in another chapter of this
tutorial) should look something like this:
<Window x:Class="WpfApplication1.MainWindow"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
</Grid>
</Window>
This is the base XAML that Visual Studio creates for our window, all parts of it explained in the chapters on
XAML and "The Window". You can actually run the application now (select Debug -> Start debugging or
press F5) to see the empty window that our application currently consists of, but now it's time to get our
message on the screen. We'll do it by adding a TextBlock control to the Grid panel, with our
aforementioned message as the content:
<Window x:Class="WpfApplication1.MainWindow"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
Try running the application now (select Debug -> Start debugging or press F5) and see the beautiful result
of your hard work - your first WPF application:
You will notice that we used three different attributes on the TextBlock to get a custom alignment (in the
middle of the window), as well the FontSize property to get bigger text. All of these concepts will be treated
in later articles.
Congratulations on making it this far. Now go read the rest of the tutorial and soon you will master WPF!
This is not really a XAML tutorial, but I will briefly tell you about how you use it, because it's such an
essential part of WPF. Whether you're creating a Window or a Page, it will consist of a XAML document
and a CodeBehind file, which together creates the Window/Page. The XAML file describes the interface
with all its elements, while the CodeBehind handles all the events and has access to manipulate with the
XAML controls.
In the next chapters, we will have a look at how XAML works and how you use it to create your interface.
<Button>
XAML tags has to be ended, either by writing the end tag or by putting a forward slash at the end of the
start tag:
<Button></Button>
Or
<Button />
A lot of controls allow you to put content between the start and end tags, which is then the content of the
control. For instance, the Button control allows you to specify the text shown on it between the start and
end tags:
<Button>A button</Button>
HTML is not case-sensitive, but XAML is, because the control name has to correspond to a type in the
.NET framework. The same goes for attribute names, which corresponds to the properties of the control.
Here's a button where we define a couple of properties by adding attributes to the tag:
We set the FontWeight property, giving us bold text, and then we set the Content property, which is the
same as writing the text between the start and end tag. However, all attributes of a control may also be
defined like this, where they appear as child tags of the main control, using the Control-Dot-Property
notation:
<Button>
<Button.FontWeight>Bold</Button.FontWeight>
<Button.Content>A button</Button.Content>
</Button>
The result is exactly the same as above, so in this case, it's all about syntax and nothing else. However, a
lot of controls allow content other than text, for instance other controls. Here's an example where we have
text in different colors on the same button by using several TextBlock controls inside of the Button:
<Button>
The Content property only allows for a single child element, so we use a WrapPanel to contain the
differently colored blocks of text. Panels, like the WrapPanel, plays an important role in WPF and we will
discuss them in much more details later on - for now, just consider them as containers for other controls.
The exact same result can be accomplished with the following markup, which is simply another way of
writing the same:
<Button FontWeight="Bold">
<WrapPanel>
<TextBlock Foreground="Blue">Multi</TextBlock>
<TextBlock Foreground="Red">Color</TextBlock>
<TextBlock>Button</TextBlock>
</WrapPanel>
</Button>
btn.Content = pnl;
pnlMain.Children.Add(btn);
Of course the above example could be written less explicitly and using more syntactical sugar, but I think
the point still stands: XAML is pretty short and concise for describing interfaces.
There are many types of events, but some of the most commonly used are there to respond to the user's
interaction with your application using the mouse or the keyboard. On most controls you will find events like
KeyDown, KeyUp, MouseDown, MouseEnter, MouseLeave, MouseUp and several others.
We will look more closely at how events work in WPF, since this is a complex topic, but for now, you need
to know how to link a control event in XAML to a piece of code in your Code-behind file. Have a look at this
example:
<Window x:Class="WpfTutorialSamples.XAML.EventsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="EventsSample" Height="300" Width="300">
<Grid Name="pnlMainGrid" MouseUp="pnlMainGrid_MouseUp" Background
="LightBlue">
</Grid>
</Window>
Notice how we have subscribed to the MouseUp event of the Grid by writing a method name. This method
needs to be defined in code-behind, using the correct event signature. In this case it should look like this:
The MouseUp event uses a delegate called MouseButtonEventHandler, which you subscribe to. It has
two parameters, a sender (the control which raised the event) and a MouseButtonEventArgs object that will
contain useful information. We use it in the example to get the position of the mouse cursor and tell the
user about it.
Several events may use the same delegate type - for instance, both MouseUp and MouseDown uses the
MouseButtonEventHandler delegate, while the MouseMove event uses the MouseEventHandler
delegate. When defining the event handler method, you need to know which delegate it uses and if you
Fortunately, Visual Studio can help us to generate a correct event handler for an event. The easiest way to
do this is to simply write the name of the event in XAML and then let the IntelliSense of VS do the rest for
you:
When you select <New Event Handler> Visual Studio will generate an appropriate event handler in
your Code-behind file. It will be named <control name>_<event name>, in our case
pnlMainGrid_MouseDown. Right-click in the event name and select Navigate to Event Handler and VS
will take you right to it.
using System;
using System.Windows;
using System.Windows.Input;
namespace WpfTutorialSamples.XAML
{
public partial class EventsSample : Window
{
public EventsSample()
{
InitializeComponent();
pnlMainGrid.MouseUp += new
MouseButtonEventHandler(pnlMainGrid_MouseUp);
}
}
}
Once again, you need to know which delegate to use, and once again, Visual Studio can help you with this.
As soon as you write:
pnlMainGrid.MouseDown +=
Simply press the [Tab] key twice to have Visual Studio generate the correct event handler for you, right
below the current method, ready for imeplentation. When you subscribe to the events like this, you don't
need to do it in XAML.
A WPF application requires the .NET framework to run, just like any other .NET application type.
Fortunately, Microsoft has been including the .NET framework on all versions of Windows since Vista, and
they have been pushing out the framework on older versions through Windows Update. In other words, you
can be pretty sure that most Windows users out there will be able to run your WPF application.
In the following chapters we will have a look at the structure and various aspects of a WPF application.
<Window x:Class="WpfApplication1.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
</Grid>
</Window>
The x:class attribute tells the XAML file which class to use, in this case Window1, which Visual Studio has
created for us as well. You will find it in the project tree in VS, as a child node of the XAML file. By default, it
looks something like this:
using System;
using System.Windows;
using System.Windows.Controls;
//more using statements
namespace WpfApplication1
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
}
}
}
As you can see, the Window1 class is definied as partial, because it's being combined with your XAML file
in runtime to give you the full window. This is actually what the call to InitializeComponent() does, which is
why it's required to get a full functioning window up and running.
You will also notice that Visual Studio has created a Grid control for us inside the Window. The Grid is one
of the WPF panels, and while it could be any panel or control, the Window can only have ONE child control,
so a Panel, which in turn can contain multiple child controls, is usually a good choice. Later in this tutorial,
we will have a much closer look into the different types of panels that you can use, as they are very
important in WPF.
Icon - Allows you to define the icon of the window, which is usually shown in the upper right corner, right
before the window title.
ResizeMode - This controls whether and how the end-user can resize your window. The default is
CanResize, which allows the user to resize the window like any other window, either by using the
maximize/minimize buttons or by dragging one of the edges. CanMinimize will allow the user to minimize
the window, but not to maximize it or drag it bigger or smaller. NoResize is the strictest one, where the
maximize and minimize buttons are removed and the window can't be dragged bigger or smaller.
ShowInTaskbar - The default is true, but if you set it to false, your window won't be represented in the
Windows taskbar. Useful for non-primary windows or for applications that should minimize to the tray.
SizeToContent - Decide if the Window should resize itself to automatically fit its content. The default is
Manual, which means that the window doesn't automatically resize. Other options are Width, Height and
WidthAndHeight, and each of them will automatically adjust the window size horizontally, vertically or both.
Topmost - The default is false, but if set to true, your Window will stay on top of other windows unless
minimized. Only useful for special situations.
WindowStartupLocation - Controls the initial position of your window. The default is Manual, which means
that the window will be initially positioned according to the Top and Left properties of your window. Other
options are CenterOwner, which will position the window in the center of it's owner window, and
CenterScreen, which will position the window in the center of the screen.
WindowState - Controls the initial window state. It can be either Normal, Maximized or Minimized. The
default is Normal, which is what you should use unless you want your window to start either maximized or
minimized.
App.xaml.cs extends the Application class, which is a central class in a WPF Windows application. .NET
will go to this class for starting instructions and then start the desired Window or Page from there. This is
also the place to subscribe to important application events, like application start, unhandled exceptions and
so on. More about that later.
One of the most commonly used features of the App.xaml file is to define global resources that may be
used and accessed from all over an application, for instance global styles. This will be discussed in detail
later on.
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml">
<Application.Resources>
</Application.Resources>
</Application>
The main thing to notice here is the StartupUri property. This is actually the part that instructs which
Window or Page to start up when the application is launched. In this case, MainWindow.xaml will be
started, but if you would like to use another window as the starting point, you can simply change this.
In some situations, you want more control over how and when the first window is displayed. In that case,
you can remove the StartupUri property and value and then do it all from Code-Behind instead. This will be
demonstrated below.
using System;
namespace WpfTutorialSamples
{
public partial class App : Application
{
}
}
You will see how this class extends the Application class, allowing us to do stuff on the application level.
For instance, you can subscribe to the Startup event, where you can manually create your starting window.
Here's an example:
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Startup="Application_Startup">
<Application.Resources></Application.Resources>
</Application>
Notice how the StartupUri has been replaced with a subscription to the Startup event (subscribing to events
through XAML is explained in another chapter). In Code-Behind, you can use the event like this:
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples
{
public partial class App : Application
{
The cool thing in this example, compared to just using the StartupUri property, is that we get to manipulate
the startup window before showing it. In this, we change the title of it, which is not terribly useful, but you
could also subscribe to events or perhaps show a splash screen. When you have all the control, there are
many possibilities. We will look deeper into several of them in the next articles of this tutorial.
notepad.exe c:\Windows\win.ini
This will open Notepad with the win.ini file opened (you may have to adjust the path to match your system).
Notepad simply looks for one or several parameters and then uses them and your application can do the
same!
Command-line parameters are passed to your WPF application through the Startup event, which we
subscribed to in the App.xaml article. We will do the same in this example, and then use the value passed
on to through the method arguments. First, the App.xaml file:
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Startup="Application_Startup">
<Application.Resources></Application.Resources>
</Application>
All we do here is to subscribe to the Startup event, replacing the StartupUri property. The event is then
implemented in App.xaml.cs:
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples
{
public partial class App : Application
{
The StartupEventArgs is what we use here. It's passed into the Application Startup event, with the name
e. It has the property Args, which is an array of strings. Command-line parameters are separated by
spaces, unless the space is inside a quoted string.
Try running the application and you will see it respond to your parameter. Of course, the message isn't
terribly useful. Instead you might want to either pass it to the constructor of your main window or call a
public open method on it, like this:
using System;
using System.Collections.Generic;
using System.Windows;
The concept is used a lot for styles and templates, which we'll discuss later on in this tutorial, but as it will
be illustrated in this chapter, you can use it for many other things as well. Allow me to demonstrate it with a
simple example:
<Window x:Class="WpfTutorialSamples.WPF_Application.ResourceSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="ResourceSample" Height="150" Width="350">
<Window.Resources>
<sys:String x:Key="strHelloWorld">Hello, world!</sys:String>
</Window.Resources>
<StackPanel Margin="10">
<TextBlock Text="{StaticResource strHelloWorld}" FontSize="56"
/>
<TextBlock>Just another "<TextBlock Text="{StaticResource
strHelloWorld}" />" example, but with resources!</TextBlock>
</StackPanel>
</Window>
Resources are given a key, using the x:Key attribute, which allows you to reference it from other parts of
the application by using this key, in combination with the StaticResource markup extension. In this
example, I just store a simple string, which I then use from two different TextBlock controls.
The main difference is that a static resource is resolved only once, which is at the point where the XAML is
loaded. If the resource is then changed later on, this change will not be reflected where you have used the
StaticResource.
A DynamicResource on the other hand, is resolved once it's actually needed, and then again if the
resource changes. Think of it as binding to a static value vs. binding to a function that monitors this value
and sends it to you each time it's changed - it's not exactly how it works, but it should give you a better idea
of when to use what. Dynamic resources also allows you to use resources which are not even there during
design time, e.g. if you add them from Code-behind during the startup of the application.
<Window x:Class
="WpfTutorialSamples.WPF_Application.ExtendedResourceSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="ExtendedResourceSample" Height="160" Width="300"
Background="{DynamicResource WindowBackgroundBrush}">
<Window.Resources>
<sys:String x:Key="ComboBoxTitle">Items:</sys:String>
<LinearGradientBrush x:Key="WindowBackgroundBrush">
<GradientStop Offset="0" Color="Silver"/>
<GradientStop Offset="1" Color="Gray"/>
</LinearGradientBrush>
</Window.Resources>
This time, we've added a couple of extra resources, so that our Window now contains a simple string, an
array of strings and a LinearGradientBrush. The string is used for the label, the array of strings is used as
items for the ComboBox control and the gradient brush is used as background for the entire window. So, as
you can see, pretty much anything can be stored as a resource.
If you only need a given resource for a specific control, you can make it more local by adding it to this
specific control, instead of the window. It works exactly the same way, the only difference being that you
can now only access from inside the scope of the control where you put it:
<StackPanel Margin="10">
<StackPanel.Resources>
<sys:String x:Key="ComboBoxTitle">Items:</sys:String>
</StackPanel.Resources>
<Label Content="{StaticResource ComboBoxTitle}" />
</StackPanel>
In this case, we add the resource to the StackPanel and then use it from its child control, the Label. Other
controls inside of the StackPanel could have used it as well, just like children of these child controls would
have been able to access it. Controls outside of this particular StackPanel wouldn't have access to it,
though.
If you need the ability to access the resource from several windows, this is possible as well. The App.xaml
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
StartupUri="WPF application/ExtendedResourceSample.xaml"
>
<Application.Resources>
<sys:String x:Key="ComboBoxTitle">Items:</sys:String>
</Application.Resources>
</Application>
Using it is also the same - WPF will automatically go up the scope, from the local control to the window
and then to App.xaml, to find a given resource:
App.xaml:
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
StartupUri="WPF
application/ResourcesFromCodeBehindSample.xaml">
<Application.Resources>
<sys:String x:Key="strApp">Hello, Application world!</
sys:String>
</Application.Resources>
</Application>
<Window x:Class
="WpfTutorialSamples.WPF_Application.ResourcesFromCodeBehindSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:sys="clr-namespace:System;assembly=mscorlib"
Title="ResourcesFromCodeBehindSample" Height="175" Width="250"
>
<Window.Resources>
<sys:String x:Key="strWindow">Hello, Window world!</sys:String
>
</Window.Resources>
<DockPanel Margin="10" Name="pnlMain">
<DockPanel.Resources>
<sys:String x:Key="strPanel">Hello, Panel world!</
sys:String>
</DockPanel.Resources>
Code-behind:
using System;
using System.Windows;
namespace WpfTutorialSamples.WPF_Application
{
public partial class ResourcesFromCodeBehindSample : Window
{
public ResourcesFromCodeBehindSample()
{
So, as you can see, we store three different "Hello, world!" messages: One in App.xaml, one inside the
window, and one locally for the main panel. The interface consists of a button and a ListBox.
In Code-behind, we handle the click event of the button, in which we add each of the text strings to the
ListBox, as seen on the screenshot. We use the FindResource() method, which will return the resource as
an object (if found), and then we turn it into the string that we know it is by using the ToString() method.
Notice how we use the FindResource() method on different scopes - first on the panel, then on the window
and then on the current Application object. It makes sense to look for the resource where we know it is,
but as already mentioned, if a resource is not found, the search progresses up the hierarchy, so in
principal, we could have used the FindResource() method on the panel in all three cases, since it would
have continued up to the window and later on up to the application level, if not found.
The same is not true the other way around - the search doesn't navigate down the tree, so you can't start
looking for a resource on the application level, if it has been defined locally for the control or for the window.
Obviously it will go wrong, since I try to perform the Trim() method on a variable that's currently null. If you
don't handle the exception, your application will crash and Windows will have to deal with the problem. As
you can see, that isn't very user friendly:
In this case, the user would be forced to close your application, due to such a simple and easily avoided
error. So, if you know that things might go wrong, then you should use a try-catch block, like this:
However, sometimes even the simplest code can throw an exception, and instead of wrapping every single
line of code with a try- catch block, WPF lets you handle all unhandled exceptions globally. This is done
through the DispatcherUnhandledException event on the Application class. If subscribed to, WPF will call
the subscribing method once an exception is thrown which is not handled in your own code. Here's a
complete example, based on the stuff we just went through:
<Window x:Class
="WpfTutorialSamples.WPF_Application.ExceptionHandlingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ExceptionHandlingSample" Height="200" Width="200">
<Grid>
<Button HorizontalAlignment="Center" VerticalAlignment
="Center" Click="Button_Click">
Do something bad!
</Button>
</Grid>
</Window>
using System;
using System.Windows;
namespace WpfTutorialSamples.WPF_Application
{
public partial class ExceptionHandlingSample : Window
{
public ExceptionHandlingSample()
{
InitializeComponent();
}
Notice that I call the Trim() method an extra time, outside of the try-catch block, so that the first call is
handled, while the second is not. For the second one, we need the App.xaml magic:
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
DispatcherUnhandledException
="Application_DispatcherUnhandledException"
StartupUri="WPF
Application/ExceptionHandlingSample.xaml">
<Application.Resources>
</Application.Resources>
</Application>
using System;
using System.Windows;
namespace WpfTutorialSamples
{
public partial class App : Application
{
private void Application_DispatcherUnhandledException(object
sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs
We handle the exception much like the local one, but with a slightly different text and image in the
message box. Also, notice that I set the e.Handled property to true. This tells WPF that we're done dealing
with this exception and nothing else should be done about it.
1.4.6.1. Summary
Exception handling is a very important part of any application and fortunately, WPF and .NET makes it
very easy to handle exceptions both locally and globally. You should handle exceptions locally when it
makes sense and only use the global handling as a fallback mechanism, since local handling allows you to
be more specific and deal with the problem in a more specialized way.
The TextBlock control is one of the most fundamental controls in WPF, yet it's very useful. It allows you to
put text on the screen, much like a Label control does, but in a simpler and less resource demanding way.
A common understanding is that a Label is for short, one-line texts (but may include e.g. an image), while
the TextBlock works very well for multiline strings as well, but can only contain text (strings). Both the Label
and the TextBlock offers their own unique advantages, so what you should use very much depends on the
situation.
We already used a TextBlock control in the "Hello, WPF!" article, but for now, let's have a look at the
TextBlock in its simplest form:
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBlockSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockSample" Height="100" Width="200">
<Grid>
<TextBlock>This is a TextBlock</TextBlock>
</Grid>
</Window>
That's as simple as it comes and if you have read the previous chapters of this tutorial, then there should
be nothing new here. The text between the TextBlock is simply a shortcut for setting the Text property of
the TextBlock.
For the next example, let's try a longer text to show how the TextBlock deals with that. I've also added a bit
of margin, to make it look just a bit better:
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBlockSample"
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBlockSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockSample" Height="200" Width="250">
<StackPanel>
<TextBlock Margin="10" Foreground="Red">
This is a TextBlock control<LineBreak />
with multiple lines of text.
</TextBlock>
<TextBlock Margin="10" TextTrimming="CharacterEllipsis"
Foreground="Green">
This is a TextBlock control with text that may not be
rendered completely, which will be indicated with an ellipsis.
</TextBlock>
<TextBlock Margin="10" TextWrapping="Wrap" Foreground="Blue">
This is a TextBlock control with automatically wrapped
text, using the TextWrapping property.
So, we have three TextBlock controls, each with a different color (using the Foreground property) for an
easier overview. They all handle the fact that their text content is too long in different ways:
The red TextBlock uses a LineBreak tag to manually break the line at a designated location. This gives
you absolute control over where you want the text to break onto a new line, but it's not very flexible for most
situations. If the user makes the window bigger, the text will still wrap at the same position, even though
there may now be room enough to fit the entire text onto one line.
The green TextBlock uses the TextTrimming property with the value CharacterEllipsis to make the
TextBlock show an ellipsis (...) when it can't fit any more text into the control. This is a common way of
showing that there's more text, but not enough room to show it. This is great when you have text that might
be too long but you absolutely don't want it to use more than one line. As an alternative to
CharacterEllipsis you may use WordEllipsis, which will trim the text at the end of the last possible word
instead of the last possible character, preventing that a word is only shown in part.
The blue TextBlock uses the TextWrapping property with the value Wrap, to make the TextBlock wrap to
the next line whenever it can't fit anymore text into the previous line. Contrary to the first TextBlock, where
we manually define where to wrap the text, this happens completely automatic and even better: It's also
automatically adjusted as soon as the TextBlock get more or less space available. Try making the window
in the example bigger or smaller and you will see how the wrapping is updated to match the situation.
This was all about dealing with simple strings in the TextBlock. In the next chapter, we'll look into some of
the more advanced functionality of the TextBlock, which allows us to create text of various styles within the
TextBlock and much more.
Luckily the TextBlock control supports inline content. These small control-like constructs all inherit from the
Inline class, which means that they can be rendered inline, as a part of a larger text. As of writing, the
supported elements include AnchoredBlock, Bold, Hyperlink, InlineUIContainer, Italic, LineBreak, Run,
Span, and Underline. In the following examples, we'll have a look at most of them.
<Window x:Class
="WpfTutorialSamples.Basic_controls.TextBlockInlineSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockInlineSample" Height="100" Width="300">
<Grid>
<TextBlock Margin="10" TextWrapping="Wrap">
TextBlock with <Bold>bold</Bold>, <Italic>italic</Italic>
and <Underline>underlined</Underline> text.
</TextBlock>
</Grid>
</Window>
Much like with HTML, you just surround your text with a Bold tag to get bold text and so on. This makes it
very easy to create and display diverse text in your applications.
All three of these tags are just child classes of the Span element, each setting a specific property on the
Span element to create the desired effect. For instance, the Bold tag just sets the FontWeight property on
the underlying Span element, the Italic element sets the FontStyle and so on.
1.5.2.3. Hyperlink
The Hyperlink element allows you to have links in your text. It's rendered with a style that suits your current
Windows theme, which will usually be some sort of underlined blue text with a red hover effect and a hand
mouse cursor. You can use the NavigateUri property to define the URL that you wish to navigate to. Here's
an example:
<Window x:Class
="WpfTutorialSamples.Basic_controls.TextBlockHyperlinkSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockHyperlinkSample" Height="100" Width="300">
<Grid>
<TextBlock Margin="10" TextWrapping="Wrap">
This text has a <Hyperlink RequestNavigate
="Hyperlink_RequestNavigate" NavigateUri="https://www.google.com">link</
Hyperlink> in it.
</TextBlock>
</Grid>
</Window>
The Hyperlink is also used inside of WPF Page's, where it can be used to navigate between pages. In that
case, you won't have to specifically handle the RequestNavigate event, like we do in the example, but for
launching external URL's from a regular WPF application, we need a bit of help from this event and the
Process class. We subscribe to the RequestNavigate event, which allows us to launch the linked URL in
the users default browser with a simple event handler like this one in the code behind file:
1.5.2.4. Run
The Run element allows you to style a string using all the available properties of the Span element, but
while the Span element may contain other inline elements, a Run element may only contain plain text. This
makes the Span element more flexible and therefore the logical choice in most cases.
1.5.2.5. Span
The Span element doesn't have any specific rendering by default, but allows you to set almost any kind of
specific rendering, including font size, style and weight, background and foreground colors and so on. The
great thing about the Span element is that it allows for other inline elements inside of it, making it easy to
do even advanced combinations of text and style. In the following example, I have used many Span
elements to show you some of the many possibilities when using inline Span elements:
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBlockSpanSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockSpanSample" Height="100" Width="300">
<Grid>
<TextBlock Margin="10" TextWrapping="Wrap">
This <Span FontWeight="Bold">is</Span> a
<Span Background="Silver" Foreground="Maroon">TextBlock</Span>
So as you can see, if none of the other elements doesn't make sense in your situation or if you just want a
blank canvas when starting to format your text, the Span element is a great choice.
<Window x:Class
="WpfTutorialSamples.Basic_controls.TextBlockCodeBehindSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBlockCodeBehindSample" Height="100" Width="300">
<Grid></Grid>
</Window>
using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Media;
namespace WpfTutorialSamples.Basic_controls
{
public partial class TextBlockCodeBehindSample : Window
{
public TextBlockCodeBehindSample()
{
InitializeComponent();
TextBlock tb = new TextBlock();
tb.TextWrapping = TextWrapping.Wrap;
tb.Margin = new Thickness(10);
tb.Inlines.Add("An example on ");
tb.Inlines.Add(new Run("the TextBlock control ") {
FontWeight = FontWeights.Bold });
tb.Inlines.Add("using ");
tb.Inlines.Add(new Run("inline ") { FontStyle =
FontStyles.Italic });
tb.Inlines.Add(new Run("text formatting ") { Foreground =
Brushes.Blue });
tb.Inlines.Add("from ");
tb.Inlines.Add(new Run("Code-Behind") { TextDecorations =
It's great to have the possibility, and it can be necessary to do it like this in some cases, but this example
will probably make you appreciate XAML even more.
<Window x:Class="WpfTutorialSamples.Basic_controls.LabelControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="LabelControlSample" Height="100" Width="200">
<Grid>
<Label Content="This is a Label control." />
</Grid>
</Window>
Another thing you might notice is the fact that the Label, by default, has a bit of padding, allowing the text to
be rendered a few pixels away from the top, left corner. This is not the case for the TextBlock control,
where you will have to specify it manually.
In a simple case like this, where the content is simply a string, the Label will actually create a TextBlock
internally and show your string in that.
• Specify a border
• Render other controls, e.g. an image
• Use templated content through the ContentTemplate property
• Use access keys to give focus to related controls
The last bullet point is actually one of the main reasons for using a Label over the TextBlock control.
Whenever you just want to render simple text, you should use the TextBlock control, since it's lighter and
performs better than the Label in most cases.
<Window x:Class="WpfTutorialSamples.Basic_controls.LabelControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="LabelControlSample" Height="180" Width="250">
<StackPanel Margin="10">
<Label Content="_Name:" Target="{Binding ElementName=txtName}"
/>
<TextBox Name="txtName" />
<Label Content="_Mail:" Target="{Binding ElementName=txtMail}"
/>
<TextBox Name="txtMail" />
</StackPanel>
</Window>
The screenshot shows our sample dialog as it looks when the Alt key is pressed. Try running it, holding
down the [Alt] key and then pressing N and M. You will see how focus is moved between the two textboxes.
So, there's several new concepts here. First of all, we define the access key by placing an underscore (_)
before the character. It doesn't have to be the first character, it can be before any of the characters in your
label content. The common practice is to use the first character that's not already used as an access key
for another control.
We use the Target property to connect the Label and the designated control. We use a standard WPF
binding for this, using the ElementName property, all of which we will describe later on in this tutorial. The
<Window x:Class
="WpfTutorialSamples.Basic_controls.LabelControlAdvancedSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="LabelControlAdvancedSample" Height="180" Width="250">
<StackPanel Margin="10">
<Label Target="{Binding ElementName=txtName}">
<StackPanel Orientation="Horizontal">
<Image Source
="http://cdn1.iconfinder.com/data/icons/fatcow/16/bullet_green.png" />
<AccessText Text="_Name:" />
</StackPanel>
</Label>
<TextBox Name="txtName" />
<Label Target="{Binding ElementName=txtMail}">
<StackPanel Orientation="Horizontal">
<Image Source
="http://cdn1.iconfinder.com/data/icons/fatcow/16/bullet_blue.png" />
<AccessText Text="_Mail:" />
</StackPanel>
</Label>
<TextBox Name="txtMail" />
</StackPanel>
</Window>
This is just an extended version of the previous example - instead of a simple text string, our Label will now
host both and image and a piece of text (inside the AccessText control, which allows us to still use an
access key for the label). Both controls are inside a horizontal StackPanel, since the Label, just like any
other ContentControl derivate, can only host one direct child control.
The Image control, described later in this tutorial, uses a remote image - this is ONLY for demonstrational
purposes and is NOT a good idea for most real life applications.
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBoxSample" Height="80" Width="250">
<StackPanel Margin="10">
<TextBox />
</StackPanel>
</Window>
That's all you need to get a text field. I added the text after running the sample and before taking the
screenshot, but you can do it through markup as well, to pre-fill the textbox, using the Text property:
Try right-clicking in the TextBox. You will get a menu of options, allowing you to use the TextBox with the
Windows Clipboard. The default keyboard shortcuts for undoing and redoing (Ctrl+Z and Ctrl+Y) should
also work, and all of this functionality you get for free!
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBoxSample"
xmlns
I have added two properties: The AcceptsReturn makes the TextBox into a multi-line control by allowing
the use of the Enter/Return key to go to the next line, and the TextWrapping property, which will make the
text wrap automatically when the end of a line is reached.
<Window x:Class="WpfTutorialSamples.Basic_controls.TextBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBoxSample" Height="160" Width="280">
<Grid Margin="10">
<TextBox AcceptsReturn="True" TextWrapping="Wrap"
SpellCheck.IsEnabled="True" Language="en-US" />
</Grid>
</Window>
We have used the previous, multi-line textbox example as the basis and then I have added two new
properties: The attached property from the SpellCheck class called IsEnabled, which simply enables spell
<Window x:Class
="WpfTutorialSamples.Basic_controls.TextBoxSelectionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextBoxSelectionSample" Height="150" Width="300">
<DockPanel Margin="10">
<TextBox SelectionChanged="TextBox_SelectionChanged"
DockPanel.Dock="Top" />
<TextBox Name="txtStatus" AcceptsReturn="True" TextWrapping
="Wrap" IsReadOnly="True" />
</DockPanel>
</Window>
The example consists of two TextBox controls: One for editing and one for outputting the current selection
status to. For this, we set the IsReadOnly property to true, to prevent editing of the status TextBox. We
subscribe the SelectionChanged event on the first TextBox, which we handle in the Code-behind:
using System;
using System.Text;
using System.Windows;
using System.Windows.Controls;
SelectionStart , which gives us the current cursor position or if there's a selection: Where it starts.
SelectionLength , which gives us the length of the current selection, if any. Otherwise it will just return 0.
SelectedText , which gives us the currently selected string if there's a selection. Otherwise an empty string
is returned.
<Window x:Class="WpfTutorialSamples.Basic_controls.CheckBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CheckBoxSample" Height="140" Width="250">
<StackPanel Margin="10">
<Label FontWeight="Bold">Application Options</Label>
<CheckBox>Enable feature ABC</CheckBox>
<CheckBox IsChecked="True">Enable feature XYZ</CheckBox>
<CheckBox>Enable feature WWW</CheckBox>
</StackPanel>
</Window>
As you can see, the CheckBox is very easy to use. On the second CheckBox, I use the IsChecked
property to have it checked by default, but other than that, no properties are needed to use it. The
IsChecked property should also be used from Code-behind if you want to check whether a certain
CheckBox is checked or not.
<Window x:Class="WpfTutorialSamples.Basic_controls.CheckBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
As you can see from the sample markup, you can do pretty much whatever you want with the content. On
all three check boxes, I do something differently with the text, and on the middle one I even throw in an
Image control. By specifying a control as the content, instead of just text, we get much more control of the
appearance, and the cool thing is that no matter which part of the content you click on, it will activate the
A common usage for this is to have a "Enable all" CheckBox, which can control a set of child checkboxes,
as well as show their collective state. Our example shows how you may create a list of features that can be
toggled on and off, with a common "Enable all" CheckBox in the top:
<Window x:Class
="WpfTutorialSamples.Basic_controls.CheckBoxThreeStateSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CheckBoxThreeStateSample" Height="170" Width="300">
<StackPanel Margin="10">
<Label FontWeight="Bold">Application Options</Label>
<StackPanel Margin="10,5">
<CheckBox IsThreeState="True" Name="cbAllFeatures"
Checked="cbAllFeatures_CheckedChanged" Unchecked
="cbAllFeatures_CheckedChanged">Enable all</CheckBox>
<StackPanel Margin="20,5">
<CheckBox Name="cbFeatureAbc" Checked
="cbFeature_CheckedChanged" Unchecked="cbFeature_CheckedChanged">Enable
feature ABC</CheckBox>
<CheckBox Name="cbFeatureXyz" IsChecked="True"
Checked="cbFeature_CheckedChanged" Unchecked="cbFeature_CheckedChanged">
Enable feature XYZ</CheckBox>
<CheckBox Name="cbFeatureWww" Checked
="cbFeature_CheckedChanged" Unchecked="cbFeature_CheckedChanged">Enable
feature WWW</CheckBox>
</StackPanel>
</StackPanel>
</StackPanel>
</Window>
using System;
using System.Windows;
}
}
All of this behavior can be seen on the screenshots above, and is achieved by subscribing to the Checked
and Unchecked events of the CheckBox controls. In a real world example, you would likely bind the values
instead, but this example shows the basics of using the IsThreeState property to create a "Toggle all"
effect.
<Window x:Class="WpfTutorialSamples.Basic_controls.RadioButtonSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="RadioButtonSample" Height="150" Width="250">
<StackPanel Margin="10">
<Label FontWeight="Bold">Are you ready?</Label>
<RadioButton>Yes</RadioButton>
<RadioButton>No</RadioButton>
<RadioButton IsChecked="True">Maybe</RadioButton>
</StackPanel>
</Window>
All we do is add a Label with a question, and then three radio buttons, each with a possible answer. We
define a default option by using the IsChecked property on the last RadioButton, which the user can
change simply by clicking on one of the other radio buttons. This is also the property you would want to
use from Code-behind to check if a RadioButton is checked or not.
<Window x:Class="WpfTutorialSamples.Basic_controls.RadioButtonSample"
xmlns
With the GroupName property set on each of the radio buttons, a selection can now be made for each of
the two groups. Without this, only one selection for all six radio buttons would be possible.
Markup-wise, this example gets a bit heavy, but the concept is pretty simple. For each RadioButton, we
have a WrapPanel with an image and a piece of text inside of it. Since we now take control of the text using
a TextBlock control, this also allows us to format the text in any way we want to. For this example, I have
changed the text color to match the choice. An Image control (read more about those later) is used to
display an image for each choice.
<Window x:Class="WpfTutorialSamples.Basic_controls.PasswordBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="PasswordBoxSample" Height="160" Width="300">
<StackPanel Margin="10">
<Label>Text:</Label>
<TextBox />
<Label>Password:</Label>
<PasswordBox />
</StackPanel>
</Window>
In the screenshot, I have entered the exact same text into the two text boxes, but in the password version,
the characters are replaced with dots. You can actually control which character is used instead of the real
characters, using the PasswordChar property:
In this case, the character X will be used instead of the dots. In case you need to control the length of the
password, there's a MaxLength property for you:
Notice how the characters are now X's instead, and that I was only allowed to enter 6 characters in the
box.
This may or may not be important to you - as already stated, you can still read the password from Code-
behind, but for MVVM implementations or if you just love data bindings, a workaround has been developed.
You can read much more about it here:
http://blog.functionalfun.net/2008/06/wpf-passwordbox-and-data-binding.html
Specifying a tooltip for a control is very easy, as you will see in this first and very basic example:
<Window x:Class
="WpfTutorialSamples.Control_concepts.ToolTipsSimpleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolTipsSimpleSample" Height="150" Width="400">
<Grid VerticalAlignment="Center" HorizontalAlignment="Center">
</Grid>
</Window>
As you can see on the screenshots, this results in a floating box with the specified string, once the mouse
hovers over the button. This is what most UI frameworks offers - the display of a text string and nothing
more.
However, in WPF, the ToolTip property is actually not a string type, but instead an object type, meaning
that we can put whatever we want in there. This opens up for some pretty cool possibilities, where we can
<Window x:Class
="WpfTutorialSamples.Control_concepts.ToolTipsAdvancedSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolTipsAdvancedSample" Height="200" Width="400"
UseLayoutRounding="True">
<DockPanel>
<ToolBar DockPanel.Dock="Top">
<Button ToolTip="Create a new file">
<Button.Content>
<Image Source
="/WpfTutorialSamples;component/Images/page_white.png" Width="16" Height
="16" />
</Button.Content>
</Button>
<Button>
<Button.Content>
<Image Source
="/WpfTutorialSamples;component/Images/folder.png" Width="16" Height
="16" />
</Button.Content>
<Button.ToolTip>
<StackPanel>
<TextBlock FontWeight="Bold" FontSize="14"
Margin="0,0,0,5">Open file</TextBlock>
<TextBlock>
Search your computer or local network
<LineBreak />
for a file and open it for editing.
</TextBlock>
<Border BorderBrush="Silver"
BorderThickness="0,1,0,0" Margin="0,8" />
<WrapPanel>
<Image Source
="/WpfTutorialSamples;component/Images/help.png" Margin="0,0,5,0" />
<TextBlock FontStyle="Italic">Press
F1 for more help</TextBlock>
<TextBox>
Editor area...
</TextBox>
</DockPanel>
</Window>
Notice how this example uses a simple string tooltip for the first button and then a much more advanced
one for the second button. In the advanced case, we use a panel as the root control and then we're free to
add controls to that as we please. The result is pretty cool, with a header, a description text and a hint that
you can press F1 for more help, including a help icon.
You can also control whether or not the popup should have a shadow, using the HasDropShadow
property, or whether tooltips should be displayed for disabled controls as well, using the ShowOnDisabled
property. There are several other interesting properties, so for a complete list, please consult the
documentation:
http://msdn.microsoft.com/en-us/library/system.windows.controls.tooltipservice.aspx
In this article, we'll be discussing why text is sometimes rendered more blurry with WPF, how this was
later fixed and how you can control text
rendering yourself.
As already mentioned in this tutorial, WPF does a lot more things on its own when compared to other UI
frameworks like WinForms, which will use the Windows API for many, many things. This is also clear when
it comes to the rendering of text - WinForms uses the GDI API from Windows, while WPF has its own text
rendering implementation, to better support animations as well as the device independent nature of WPF.
Unfortunately, this led to text being rendered a bit blurry, especially in small font sizes. This was a rather
big problem for WPF programmers for some time, but luckily, Microsoft made a lot of improvements in the
WPF text rendering engine in .NET framework version 4.0. This means that if you're using this version or
higher, your text should be almost as good as pixel perfect.
1.6.2.2. TextFormattingMode
Using the TextFormattingMode property, you get to decide which algorithm should be used when formatting
the text. You can choose between Ideal (the default value) and Display. You would normally want to leave
this property untouched, since the Ideal setting will be best for most situations, but in cases where you
need to render very small text, the Display setting can sometimes yield a better result. Here's an example
where you can see the difference (although it's very subtle):
<Window x:Class
="WpfTutorialSamples.Control_concepts.TextFormattingModeSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextFormattingModeSample" Height="200" Width="400">
<StackPanel Margin="10">
<Label TextOptions.TextFormattingMode="Ideal" FontSize="9">
TextFormattingMode.Ideal, small text</Label>
<Label TextOptions.TextFormattingMode="Display" FontSize="9">
1.6.2.3. TextRenderingMode
The TextRenderingMode property gives you control of which antialiasing algorithm is used when
rendering text. It has the biggest effect in combination with the Display setting for the
TextFormattingMode property, which we'll use in this example to illustrate the differences:
<Window x:Class
="WpfTutorialSamples.Control_concepts.TextRenderingModeSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TextRenderingModeSample" Height="300" Width="400">
<StackPanel Margin="10" TextOptions.TextFormattingMode="Display">
<Label TextOptions.TextRenderingMode="Auto" FontSize="9">
TextRenderingMode.Auto, small text</Label>
<Label TextOptions.TextRenderingMode="Aliased" FontSize="9">
TextRenderingMode.Aliased, small text</Label>
<Label TextOptions.TextRenderingMode="ClearType" FontSize="9">
TextRenderingMode.ClearType, small text</Label>
<Label TextOptions.TextRenderingMode="Grayscale" FontSize="9">
TextRenderingMode.Grayscale, small text</Label>
<Label TextOptions.TextRenderingMode="Auto" FontSize="18">
As you can see, the resulting text differs quite a bit in how it looks and once again, you should mainly
change this in special circumstances.
Panels come in several different flavors, with each of them having its own way of dealing with layout and
child controls. Picking the right panel is therefore essential to getting the behavior and layout you want, and
especially in the start of your WPF career, this can be a difficult job. The next section will describe each of
the panels shortly and give you an idea of when to use it. After that, move on to the next chapters, where
each of the panels will be described in detail.
1.7.1.1. Canvas
A simple panel, which mimics the WinForms way of doing things. It allows you to assign specific
coordinates to each of the child controls, giving you total control of the layout. This is not very flexible
though, because you have to manually move the child controls around and make sure that they align the
way you want them to. Use it (only) when you want complete control of the child control positions.
1.7.1.2. WrapPanel
The WrapPanel will position each of its child controls next to the other, horizontally (default) or vertically,
until there is no more room, where it will wrap to the next line and then continue. Use it when you want a
vertical or horizontal list controls that automatically wraps when there's no more room.
1.7.1.3. StackPanel
The StackPanel acts much like the WrapPanel, but instead of wrapping if the child controls take up too
much room, it simply expands itself, if possible. Just like with the WrapPanel, the orientation can be either
horizontal or vertical, but instead of adjusting the width or height of the child controls based on the largest
item, each item is stretched to take up the full width or height. Use the StackPanel when you want a list of
controls that takes up all the available room, without wrapping.
1.7.1.4. DockPanel
The DockPanel allows you to dock the child controls to the top, bottom, left or right. By default, the last
control, if not given a specific dock position, will fill the remaining space. You can achieve the same with the
Grid panel, but for the simpler situations, the DockPanel will be easier to use. Use the DockPanel whenever
you need to dock one or several controls to one of the sides, like for dividing up the window into specific
areas.
1.7.1.5. Grid
The Grid is probably the most complex of the panel types. A Grid can contain multiple rows and columns.
You define a height for each of the rows and a width for each of the columns, in either an absolute amount
1.7.1.6. UniformGrid
The UniformGrid is just like the Grid, with the possibility of multiple rows and columns, but with one
important difference: All rows and columns will have the same size! Use this when you need the Grid
behavior without the need to specify different sizes for the rows and columns.
If you have ever used another UI library like WinForms, this will probably make you feel right at home, but
while it can be tempting to have absolute control of all the child controls, this also means that the Panel
won't do anything for you once the user starts resizing your window, if you localize absolutely positioned
text or if the content is scaled.
More about that later, let's get into a simple example. This one is mostly about showing you just how little
the Canvas does by default:
<Window x:Class="WpfTutorialSamples.Panels.Canvas"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Canvas" Height="200" Width="200">
<Canvas>
<Button>Button 1</Button>
<Button>Button 2</Button>
</Canvas>
</Window>
As you can see, even though we have two buttons, they are both placed in the exact same place, so only
the last one is visible. The Canvas does absolutely nothing until you start giving coordinates to the child
controls. This is done using the Left, Right, Top and Bottom attached properties from the Canvas control.
These properties allow you to specify the position relative to the four edges of the Canvas. By default, they
are all set to NaN (Not a Number), which will make the Canvas place them in the upper left corner, but as
<Window x:Class="WpfTutorialSamples.Panels.Canvas"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Canvas" Height="200" Width="200">
<Canvas>
<Button Canvas.Left="10">Top left</Button>
<Button Canvas.Right="10">Top right</Button>
<Button Canvas.Left="10" Canvas.Bottom="10">Bottom left</
Button>
<Button Canvas.Right="10" Canvas.Bottom="10">Bottom right</
Button>
</Canvas>
</Window>
Notice how I only set the property or properties that I need. For the first two buttons, I only wish to specify
a value for the X axis, so I use the Left and Right properties to push the buttons towards the center, from
each direction.
For the bottom buttons, I use both Left/Right and Bottom to push them towards the center in both
directions. You will usually specify either a Top or a Bottom value and/or a Left or a Right value.
As mentioned, since the Canvas gives you complete control of positions, it won't really care whether or not
there's enough room for all your controls or if one is on top of another. This makes it a bad choice for pretty
much any kind of dialog design, but the Canvas is, as the name implies, great for at least one thing:
Painting. WPF has a bunch of controls that you can place inside a Canvas, to make nice illustrations.
<Window x:Class="WpfTutorialSamples.Panels.CanvasZIndex"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CanvasZIndex" Height="275" Width="260">
<Canvas>
<Ellipse Fill="Gainsboro" Canvas.Left="25" Canvas.Top="25"
Width="200" Height="200" />
<Rectangle Fill="LightBlue" Canvas.Left="25" Canvas.Top="25"
Width="50" Height="50" />
<Rectangle Fill="LightCoral" Canvas.Left="50" Canvas.Top="50"
Width="50" Height="50" />
<Rectangle Fill="LightCyan" Canvas.Left="75" Canvas.Top="75"
Width="50" Height="50" />
</Canvas>
</Window>
<Window x:Class="WpfTutorialSamples.Panels.CanvasZIndex"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CanvasZIndex" Height="275" Width="260">
<Canvas>
<Ellipse Panel.ZIndex="2" Fill="Gainsboro" Canvas.Left="25"
Canvas.Top="25" Width="200" Height="200" />
<Rectangle Panel.ZIndex="3" Fill="LightBlue" Canvas.Left="25"
Canvas.Top="25" Width="50" Height="50" />
<Rectangle Panel.ZIndex="2" Fill="LightCoral" Canvas.Left="50"
Canvas.Top="50" Width="50" Height="50" />
<Rectangle Panel.ZIndex="4" Fill="LightCyan" Canvas.Left="75"
Canvas.Top="75" Width="50" Height="50" />
</Canvas>
</Window>
The default ZIndex value is 0, but we assign a new one to each of the shapes. The rule is that the element
with the higher z-index overlaps the ones with the lower values. If two values are identical, the last defined
element "wins". As you can see from the screenshot, changing the ZIndex property gives quite another
look.
When the WrapPanel uses the Horizontal orientation, the child controls will be given the same height,
based on the tallest item. When the WrapPanel is the Vertical orientation, the child controls will be given
the same width, based on the widest item.
In the first example, we'll check out a WrapPanel with the default (Horizontal) orientation:
<Window x:Class="WpfTutorialSamples.Panels.WrapPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WrapPanel" Height="300" Width="300">
<WrapPanel>
<Button>Test button 1</Button>
<Button>Test button 2</Button>
<Button>Test button 3</Button>
<Button Height="40">Test button 4</Button>
<Button>Test button 5</Button>
<Button>Test button 6</Button>
</WrapPanel>
</Window>
Notice how I set a specific height on one of the buttons in the second row. In the resulting screenshot, you
will see that this causes the entire row of buttons to have the same height instead of the height required, as
seen on the first row. You will also notice that the panel does exactly what the name implies: It wraps the
content when it can't fit any more of it in. In this case, the fourth button couldn't fit in on the first line, so it
Should you make the window, and thereby the available space, smaller, you will see how the panel
immediately adjusts to it:
All of this behavior is also true when you set the Orientation to Vertical. Here's the exact same example as
before, but with a Vertical WrapPanel:
<Window x:Class="WpfTutorialSamples.Panels.WrapPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WrapPanel" Height="120" Width="300">
<WrapPanel Orientation="Vertical">
<Button>Test button 1</Button>
<Button>Test button 2</Button>
<Button>Test button 3</Button>
<Button Width="140">Test button 4</Button>
<Button>Test button 5</Button>
<Button>Test button 6</Button>
</WrapPanel>
</Window>
You can see how the buttons go vertical instead of horizontal, before they wrap because they reach the
Please be aware that while the Horizontal WrapPanel will match the height in the same row and the Vertical
WrapPanel will match the width in the same column, height is not matched in a Vertical WrapPanel and
width is not matched in a Horizontal WrapPanel. Take a look in this example, which is the Vertical
WrapPanel but where the fourth button gets a custom width AND height:
Notice how button 5 only uses the width - it doesn't care about the height, although it causes the sixth
button to be pushed to a new column.
<Window x:Class="WpfTutorialSamples.Panels.StackPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StackPanel" Height="160" Width="300">
<StackPanel>
<Button>Button 1</Button>
<Button>Button 2</Button>
<Button>Button 3</Button>
<Button>Button 4</Button>
<Button>Button 5</Button>
<Button>Button 6</Button>
</StackPanel>
</Window>
The first thing you should notice is how the StackPanel doesn't really care whether or not there's enough
room for the content. It doesn't wrap the content in any way and it doesn't automatically provide you with
the ability to scroll (you can use a ScrollViewer control for that though - more on that in a later chapter).
You might also notice that the default orientation of the StackPanel is Vertical, unlike the WrapPanel where
the default orientation is Horizontal. But just like for the WrapPanel, this can easily be changed, using the
Orientation property:
<StackPanel Orientation="Horizontal">
<Window x:Class="WpfTutorialSamples.Panels.StackPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StackPanel" Height="160" Width="300">
<StackPanel Orientation="Horizontal">
<Button VerticalAlignment="Top">Button 1</Button>
<Button VerticalAlignment="Center">Button 2</Button>
<Button VerticalAlignment="Bottom">Button 3</Button>
<Button VerticalAlignment="Bottom">Button 4</Button>
<Button VerticalAlignment="Center">Button 5</Button>
<Button VerticalAlignment="Top">Button 6</Button>
</StackPanel>
</Window>
<Window x:Class="WpfTutorialSamples.Panels.StackPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StackPanel" Height="160" Width="300">
<StackPanel Orientation="Vertical">
<Button HorizontalAlignment="Left">Button 1</Button>
<Button HorizontalAlignment="Center">Button 2</Button>
<Button HorizontalAlignment="Right">Button 3</Button>
<Button HorizontalAlignment="Right">Button 4</Button>
<Button HorizontalAlignment="Center">Button 5</Button>
<Button HorizontalAlignment="Left">Button 6</Button>
</StackPanel>
</Window>
As you can see, the controls still go from top to bottom, but instead of having the same width, each control
is aligned to the left, the right or center.
As we've seen with many of the other panels in WPF, you start taking advantage of the panel possibilities
by using an attached property of it, in this case the DockPanel.Dock property, which decides in which
direction you want the child control to dock to. If you don't use this, the first control(s) will be docked to the
left, with the last one taking up the remaining space. Here's an example on how you use it:
<Window x:Class="WpfTutorialSamples.Panels.DockPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DockPanel" Height="250" Width="250">
<DockPanel>
<Button DockPanel.Dock="Left">Left</Button>
<Button DockPanel.Dock="Top">Top</Button>
<Button DockPanel.Dock="Right">Right</Button>
<Button DockPanel.Dock="Bottom">Bottom</Button>
<Button>Center</Button>
</DockPanel>
</Window>
As already mentioned, we don't assign a dock position for the last child, because it automatically centers
the control, allowing it to fill the remaining space. You will also notice that the controls around the center
The last thing that you will likely notice, is how the space is divided. For instance, the Top button doesn't
get all of the top space, because the Left button takes a part of it. The DockPanel decides which control to
favor by looking at their position in the markup. In this case, the Left button gets precedence because it's
placed first in the markup. Fortunately, this also means that it's very easy to change, as we'll see in the next
example, where we have also evened out the space a bit by assigning widths/heights to the child controls:
<Window x:Class="WpfTutorialSamples.Panels.DockPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DockPanel" Height="250" Width="250">
<DockPanel>
<Button DockPanel.Dock="Top" Height="50">Top</Button>
<Button DockPanel.Dock="Bottom" Height="50">Bottom</Button>
<Button DockPanel.Dock="Left" Width="50">Left</Button>
<Button DockPanel.Dock="Right" Width="50">Right</Button>
<Button>Center</Button>
</DockPanel>
</Window>
The top and bottom controls now take precedence over the left and right controls, and they're all taking up
50 pixels in either height or width. If you make the window bigger or smaller, you will also see that this static
width/height remains the same no matter what - only the center area increases or decreases in size as you
resize the window.
<Window x:Class="WpfTutorialSamples.Panels.DockPanel"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DockPanel" Height="300" Width="300">
<DockPanel LastChildFill="False">
<Button DockPanel.Dock="Top" Height="50">Top</Button>
<Button DockPanel.Dock="Bottom" Height="50">Bottom</Button>
<Button DockPanel.Dock="Left" Width="50">Left</Button>
<Button DockPanel.Dock="Left" Width="50">Left</Button>
<Button DockPanel.Dock="Right" Width="50">Right</Button>
<Button DockPanel.Dock="Right" Width="50">Right</Button>
</DockPanel>
</Window>
In this example, we dock two controls to the left and two controls to the right, and at the same time, we turn
off the LastChildFill property. This leaves us with empty space in the center, which may be preferable in
some cases.
In its most basic form, the Grid will simply take all of the controls you put into it, stretch them to use the
maximum available space and place it on top of each other:
<Window x:Class="WpfTutorialSamples.Panels.Grid"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Grid" Height="300" Width="300">
<Grid>
<Button>Button 1</Button>
<Button>Button 2</Button>
</Grid>
</Window>
As you can see, the last control gets the top position, which in this case means that you can't even see the
first button. Not terribly useful for most situations though, so let's try dividing the space, which is what the
grid does so well. We do that by using ColumnDefinitions and RowDefinitions. In the first example, we'll
stick to columns:
<Window x:Class="WpfTutorialSamples.Panels.Grid"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Grid" Height="300" Width="300">
In this example, we have simply divided the available space into two columns, which will share the space
equally, using a "star width" (this will be explained later). On the second button, I use a so-called Attached
property to place the button in the second column (0 is the first column, 1 is the second and so on). I could
have used this property on the first button as well, but it automatically gets assigned to the first column and
the first row, which is exactly what we want here.
As you can see, the controls take up all the available space, which is the default behavior when the grid
arranges its child controls. It does this by setting the HorizontalAlignment and VerticalAlignment on its child
controls to Stretch.
In some situations you may want them to only take up the space they need though and/or control how they
are placed in the Grid. The easiest way to do this is to set the HorizontalAlignment and VerticalAlignment
directly on the controls you wish to manipulate. Here's a modified version of the above example:
<Window x:Class="WpfTutorialSamples.Panels.Grid"
As you can see from the resulting screenshot, the first button is now placed in the top and centered. The
second button is placed in the middle, aligned to the right.
<Window x:Class="WpfTutorialSamples.Panels.TabularGrid"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TabularGrid" Height="300" Width="300">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="2*" />
<ColumnDefinition Width="1*" />
<ColumnDefinition Width="1*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="2*" />
<RowDefinition Height="1*" />
<RowDefinition Height="1*" />
</Grid.RowDefinitions>
<Button>Button 1</Button>
<Button Grid.Column="1">Button 2</Button>
<Button Grid.Column="2">Button 3</Button>
<Button Grid.Row="1">Button 4</Button>
<Button Grid.Column="1" Grid.Row="1">Button 5</Button>
<Button Grid.Column="2" Grid.Row="1">Button 6</Button>
<Button Grid.Row="2">Button 7</Button>
<Button Grid.Column="1" Grid.Row="2">Button 8</Button>
<Button Grid.Column="2" Grid.Row="2">Button 9</Button>
</Grid>
</Window>
A total of nine buttons, each placed in their own cell in a grid containing three rows and three columns. We
once again use a star based width, but this time we assign a number as well - the first row and the first
column has a width of 2*, which basically means that it uses twice the amount of space as the rows and
columns with a width of 1* (or just * - that's the same).
You will also notice that I use the Attached properties Grid.Row and Grid.Column to place the controls in
the grid, and once again you will notice that I have omitted these properties on the controls where I want to
use either the first row or the first column (or both). This is essentially the same as specifying a zero. This
saves a bit of typing, but you might prefer to assign them anyway for a better overview - that's totally up to
<Window x:Class="WpfTutorialSamples.Panels.GridUnits"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridUnits" Height="200" Width="400">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="1*" />
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="100" />
</Grid.ColumnDefinitions>
<Button>Button 1</Button>
<Button Grid.Column="1">Button 2 with long text</Button>
<Button Grid.Column="2">Button 3</Button>
</Grid>
</Window>
In this example, the first button has a star width, the second one has its width set to Auto and the last one
has a static width of 100 pixels.
The result can be seen on the screenshot, where the second button only takes exactly the amount of space
it needs to render its longer text, the third button takes exactly the 100 pixels it was promised and the first
button, with the variable width, takes the rest.
On the first screenshot, you will see that the Grid reserves the space for the last two buttons, even though it
means that the first one doesn't get all the space it needs to render properly. On the second screenshot,
you will see the last two buttons keeping the exact same amount of space, leaving the surplus space to the
first button.
This can be a very useful technique when designing a wide range of dialogs. For instance, consider a
simple contact form where the user enters a name, an e-mail address and a comment. The first two fields
will usually have a fixed height, while the last one might as well take up as much space as possible, leaving
room to type a longer comment. In the next chapter, we will try building a contact form, using the grid and
rows and columns of different heights and widths.
<Window x:Class="WpfTutorialSamples.Panels.GridColRowSpan"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridColRowSpan" Height="110" Width="300">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="1*" />
<ColumnDefinition Width="1*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="*" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<Button>Button 1</Button>
<Button Grid.Column="1">Button 2</Button>
<Button Grid.Row="1" Grid.ColumnSpan="2">Button 3</Button>
</Grid>
</Window>
We just define two columns and two rows, all of them taking up their equal share of the place. The first two
buttons just use the columns normally, but with the third button, we make it take up two columns of space
on the second row, using the ColumnSpan attribute.
This is all so simple that we could have just used a combination of panels to achieve the same effect, but
for just slightly more advanced cases, this is really useful. Let's try something which better shows how
powerful this is:
So as you can see, spanning multiple columns and/or rows in a Grid is very easy. In a later article, we will
use the spanning, along with all the other Grid techniques in a more practical example.
The GridSplitter is used simply by adding it to a column or a row in a Grid, with the proper amount of space
for it, e.g. 5 pixels. It will then allow the user to drag it from side to side or up and down, while changing the
size of the column or row on each of the sides of it. Here's an example:
<Window x:Class="WpfTutorialSamples.Panels.GridSplitterSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridSplitterSample" Height="300" Width="300">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="*" />
<ColumnDefinition Width="5" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<TextBlock FontSize="55" HorizontalAlignment="Center"
VerticalAlignment="Center" TextWrapping="Wrap">Left side</TextBlock>
<GridSplitter Grid.Column="1" Width="5" HorizontalAlignment
="Stretch" />
<TextBlock Grid.Column="2" FontSize="55" HorizontalAlignment
="Center" VerticalAlignment="Center" TextWrapping="Wrap">Right side</
TextBlock>
</Grid>
</Window>
<Window x:Class="WpfTutorialSamples.Panels.GridSplitterHorizontalSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridSplitterHorizontalSample" Height="300" Width="300">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="*" />
<RowDefinition Height="5" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<TextBlock FontSize="55" HorizontalAlignment="Center"
VerticalAlignment="Center" TextWrapping="Wrap">Top</TextBlock>
<GridSplitter Grid.Row="1" Height="5" HorizontalAlignment
="Stretch" />
<TextBlock Grid.Row="2" FontSize="55" HorizontalAlignment
="Center" VerticalAlignment="Center" TextWrapping="Wrap">Bottom</
TextBlock>
</Grid>
</Window>
As you can see, I simply changed the columns into rows and on the GridSplitter, I defined a Height instead
of a Width. The GridSplitter figures out the rest on its own, but in case it doesn't, you can use the
ResizeDirection property on it to force it into either Rows or Columns mode.
The good thing about the contact form is that it's just an example of a commonly used dialog - you can take
the techniques used and apply them to almost any type of dialog that you need to create.
The first take on this task is very simple and will show you a very basic contact form. It uses three rows, two
of them with Auto heights and the last one with star height, so it consumes the rest of the available space:
<Window x:Class="WpfTutorialSamples.Panels.GridContactForm"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridContactForm" Height="300" Width="300">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<TextBox>Name</TextBox>
<TextBox Grid.Row="1">E-mail</TextBox>
<TextBox Grid.Row="2" AcceptsReturn="True">Comment</TextBox>
</Grid>
</Window>
As you can see, the last TextBox simply takes up the remaining space, while the first two only takes up the
space they require. Try resizing the window and you will see the comment TextBox resize with it.
<Window x:Class="WpfTutorialSamples.Panels.GridContactFormTake2"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="GridContactFormTake2" Height="300" Width="300">
<Grid Margin="10">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<Label>Name: </Label>
<TextBox Grid.Column="1" Margin="0,0,0,10" />
<Label Grid.Row="1">E-mail: </Label>
<TextBox Grid.Row="1" Grid.Column="1" Margin="0,0,0,10" />
<Label Grid.Row="2">Comment: </Label>
<TextBox Grid.Row="2" Grid.Column="1" AcceptsReturn="True" />
</Grid>
</Window>
So as you can see, the Grid is a very powerful panel. Hopefully you can use all of these techniques when
designing your own dialogs.
Data binding is general technique that binds two data/information sources together and maintains
synchronization of data.
With WPF, Microsoft has put data binding in the front seat and once you start learning WPF, you will
realize that it's an important aspect of pretty much everything you do. If you come from the world of
WinForms, then the huge focus on data binding might scare you a bit, but once you get used to it, you will
likely come to love it, as it makes a lot of things cleaner and easier to maintain.
Data binding in WPF is the preferred way to bring data from your code to the UI layer. Sure, you can set
properties on a control manually or you can populate a ListBox by adding items to it from a loop, but the
cleanest and purest WPF way is to add a binding between the source and the destination UI element.
1.8.1.1. Summary
In the next chapter, we'll look into a simple example where data binding is used and after that, we'll talk
some more about all the possibilities. The concept of data binding is included pretty early in this tutorial,
because it's such an integral part of using WPF, which you will see once you explore the rest of the
chapters, where it's used almost all of the time.
However, the more theoretical part of data binding might be too heavy if you just want to get started
building a simple WPF application. In that case I suggest that you have a look at the "Hello, bound world!"
article to get a glimpse of how data binding works, and then save the rest of the data binding articles for
later, when you're ready to get some more theory.
<Window x:Class="WpfTutorialSamples.DataBinding.HelloBoundWorldSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="HelloBoundWorldSample" Height="110" Width="280">
<StackPanel Margin="10">
<TextBox Name="txtValue" />
<WrapPanel Margin="0,10">
<TextBlock Text="Value: " FontWeight="Bold" />
<TextBlock Text="{Binding Path=Text,
ElementName=txtValue}" />
</WrapPanel>
</StackPanel>
</Window>
This simple example shows how we bind the value of the TextBlock to match the Text property of the
TextBox. As you can see from the screenshot, the TextBlock is automatically updated when you enter text
into the TextBox. In a non-bound world, this would require us to listen to an event on the TextBox and then
update the TextBlock each time the text changes, but with data binding, this connection can be established
just by using markup.
{Binding}
{Binding Path=NameOfProperty}
The Path notes the property that you want to bind to, however, since Path is the default property of a
binding, you may leave it out if you want to, like this:
{Binding NameOfProperty}
You will see many different examples, some of them where Path is explicitly defined and some where it's
left out. In the end it's really up to you though.
A binding has many other properties though, one of them being the ElementName which we use in our
example. This allows us to connect directly to another UI element as the source. Each property that we set
in the binding is separated by a comma:
1.8.2.2. Summary
This was just a glimpse of all the binding possibilities of WPF. In the next chapters, we'll discover more of
them, to show you just how powerful data binding is.
There's no default source for the DataContext property (it's simply null from the start), but since a
DataContext is inherited down through the control hierarchy, you can set a DataContext for the Window
itself and then use it throughout all of the child controls. Let's try illustrating that with a simple example:
<Window x:Class="WpfTutorialSamples.DataBinding.DataContextSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataContextSample" Height="130" Width="280">
<StackPanel Margin="15">
<WrapPanel>
<TextBlock Text="Window title: " />
<TextBox Text="{Binding Title,
UpdateSourceTrigger=PropertyChanged}" Width="150" />
</WrapPanel>
<WrapPanel Margin="0,10,0,0">
<TextBlock Text="Window dimensions: " />
<TextBox Text="{Binding Width}" Width="50" />
<TextBlock Text=" x " />
<TextBox Text="{Binding Height}" Width="50" />
</WrapPanel>
</StackPanel>
</Window>
using System;
using System.Windows;
namespace WpfTutorialSamples.DataBinding
{
public partial class DataContextSample : Window
{
public DataContextSample()
{
InitializeComponent();
this.DataContext = this;
The Code-behind for this example only adds one line of interesting code: After the standard
InitalizeComponent() call, we assign the "this" reference to the DataContext, which basically just tells the
Window that we want itself to be the data context.
In the XAML, we use this fact to bind to several of the Window properties, including Title, Width and
Height. Since the window has a DataContext, which is passed down to the child controls, we don't have to
define a source on each of the bindings - we just use the values as if they were globally available.
Try running the example and resize the window - you will see that the dimension changes are immediately
reflected in the textboxes. You can also try writing a different title in the first textbox, but you might be
surprised to see that this change is not reflected immediately. Instead, you have to move the focus to
another control before the change is applied. Why? Well, that's the subject for the next chapter.
1.8.3.1. Summary
Using the DataContext property is like setting the basis of all bindings down through the hierarchy of
controls. This saves you the hassle of manually defining a source for each binding, and once you really
start using data bindings, you will definitely appreciate the time and typing saved.
However, this doesn't mean that you have to use the same DataContext for all controls within a Window.
Since each control has its own DataContext property, you can easily break the chain of inheritance and
override the DataContext with a new value. This allows you to do stuff like having a global DataContext on
the window and then a more local and specific DataContext on e.g. a panel holding a separate form or
something along those lines.
Default is, obviously, the default value of the UpdateSourceTrigger. The other options are
PropertyChanged, LostFocus and Explicit. The first two has already been described, while the last one
simply means that the update has to be pushed manually through to occur, using a call to UpdateSource on
the Binding.
To see how all of these options work, I have updated the example from the previous chapter to show you
all of them:
<Window x:Class="WpfTutorialSamples.DataBinding.DataContextSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataContextSample" Height="130" Width="310">
<StackPanel Margin="15">
<WrapPanel>
<TextBlock Text="Window title: " />
<TextBox Name="txtWindowTitle" Text="{Binding Title,
UpdateSourceTrigger=Explicit}" Width="150" />
<Button Name="btnUpdateSource" Click
="btnUpdateSource_Click" Margin="5,0" Padding="5,0">*</Button>
</WrapPanel>
<WrapPanel Margin="0,10,0,0">
<TextBlock Text="Window dimensions: " />
<TextBox Text="{Binding Width,
UpdateSourceTrigger=LostFocus}" Width="50" />
<TextBlock Text=" x " />
<TextBox Text="{Binding Height,
UpdateSourceTrigger=PropertyChanged}" Width="50" />
</WrapPanel>
</StackPanel>
</Window>
using System;
namespace WpfTutorialSamples.DataBinding
{
public partial class DataContextSample : Window
{
public DataContextSample()
{
InitializeComponent();
this.DataContext = this;
}
As you can see, each of the three textboxes now uses a different UpdateSourceTrigger.
The first one is set to Explicit, which basically means that the source won't be updated unless you
manually do it. For that reason, I have added a button next to the TextBox, which will update the source
value on demand. In the Code-behind, you will find the Click handler, where we use a couple of lines of
code to get the binding from the destination control and then call the UpdateSource() method on it.
The second TextBox uses the LostFocus value, which is actually the default for a Text binding. It means
that the source value will be updated each time the destination control loses focus.
Try running the example on your own machine and see how the three textboxes act completely different:
The first value doesn't update before you click the button, the second value isn't updated until you leave the
TextBox, while the third value updates automatically on each keystroke, text change etc.
1.8.4.1. Summary
The UpdateSourceTrigger property of a binding controls how and when a changed value is sent back to
the source. However, since WPF is pretty good at controlling this for you, the default value should suffice
for most cases, where you will get the best mix of a constantly updated UI and good performance.
For those situations where you need more control of the process, this property will definitely help though.
Just make sure that you don't update the source value more often than you actually need to. If you want the
full control, you can use the Explicit value and then do the updates manually, but this does take a bit of the
fun out of working with data bindings.
The following example will show you why we need these two things:
<Window x:Class
="WpfTutorialSamples.DataBinding.ChangeNotificationSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ChangeNotificationSample" Height="150" Width="300">
<DockPanel Margin="10">
<StackPanel DockPanel.Dock="Right" Margin="10,0,0,0">
<Button Name="btnAddUser" Click="btnAddUser_Click">Add
user</Button>
<Button Name="btnChangeUser" Click="btnChangeUser_Click"
Margin="0,5">Change user</Button>
<Button Name="btnDeleteUser" Click="btnDeleteUser_Click">
Delete user</Button>
</StackPanel>
<ListBox Name="lbUsers" DisplayMemberPath="Name"></ListBox>
</DockPanel>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.DataBinding
public ChangeNotificationSample()
{
InitializeComponent();
lbUsers.ItemsSource = users;
}
In the final example, which you will find below, we have simply replaced the List<User> with an
ObservableCollection<User> - that's all it takes! This will make the Add and Delete button work, but it won't
do anything for the "Change name" button, because the change will happen on the bound data object itself
and not the source list - the second step will handle that scenario though.
<Window x:Class
="WpfTutorialSamples.DataBinding.ChangeNotificationSample"
xmlns
using System;
using System.Collections.Generic;
using System.Windows;
using System.ComponentModel;
using System.Collections.ObjectModel;
namespace WpfTutorialSamples.DataBinding
{
public partial class ChangeNotificationSample : Window
{
private ObservableCollection<User> users = new
ObservableCollection<User>();
public ChangeNotificationSample()
{
InitializeComponent();
lbUsers.ItemsSource = users;
}
1.8.5.5. Summary
As you can see, implementing INotifyPropertyChanged is pretty easy, but it does create a bit of extra code
on your classes, and adds a bit of extra logic to your properties. This is the price you will have to pay if you
want to bind to your own classes and have the changes reflected in the UI immediately. Obviously you only
have to call NotifyPropertyChanged in the setter's of the properties that you bind to - the rest can remain
the way they are.
The ObservableCollection on the other hand is very easy to deal with - it simply requires you to use this
specific list type in those situations where you want changes to the source list reflected in a binding
destination.
• You have a numeric value but you want to show zero values in one way and positive
numbers in another way
• You want to check a CheckBox based on a value, but the value is a string like "yes" or "no"
instead of a Boolean value
• You have a file size in bytes but you wish to show it as bytes, kilobytes, megabytes or
gigabytes based on how big it is
These are some of the simple cases, but there are many more. For instance, you may want to check a
checkbox based on a Boolean value, but you want it reversed, so that the CheckBox is checked if the value
is false and not checked if the value is true. You can even use a converter to generate an image for an
ImageSource, based on the value, like a green sign for true or a red sign for false - the possibilities are
pretty much endless!
For cases like this, you can use a value converter. These small classes, which implement the
IValueConverter interface, will act like middlemen and translate a value between the source and the
destination. So, in any situation where you need to transform a value before it reaches its destination or
back to its source again, you likely need a converter.
Let's implement a simple converter which takes a string as input and then returns a Boolean value, as well
as the other way around. If you're new to WPF, and you likely are since you're reading this tutorial, then
you might not know all of the concepts used in the example, but don't worry, they will all be explained after
the code listings:
<Window x:Class="WpfTutorialSamples.DataBinding.ConverterSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
using System;
using System.Windows;
using System.Windows.Data;
namespace WpfTutorialSamples.DataBinding
{
public partial class ConverterSample : Window
{
public ConverterSample()
{
InitializeComponent();
}
}
The ConvertBack() method obviously does the opposite: It assumes an input value with a Boolean type
and then returns the English word "yes" or "no" in return, with a fallback value of "no".
You may wonder about the additional parameters that these two methods take, but they're not needed in
this example. We'll use them in one of the next chapters, where they will be explained.
1.8.6.4. XAML
In the XAML part of the program, we start off by declaring an instance of our converter as a resource for
the window. We then have a TextBox, a couple of TextBlocks and a CheckBox control and this is where the
interesting things are happening: We bind the value of the TextBox to the TextBlock and the CheckBox
control and using the Converter property and our own converter reference, we juggle the values back and
forth between a string and a Boolean value, depending on what's needed.
If you try to run this example, you will be able to change the value in two places: By writing "yes" in the
TextBox (or any other value, if you want false) or by checking the CheckBox. No matter what you do, the
change will be reflected in the other control as well as in the TextBlock.
1.8.6.5. Summary
This was an example of a simple value converter, made a bit longer than needed for illustrational
purposes. In the next chapter we'll look into a more advanced example, but before you go out and write
your own converter, you might want to check if WPF already includes one for the purpose. As of writing,
there are more than 20 built-in converters that you may take advantage of, but you need to know their
name. I found the following list which might come in handy for you:
http://stackoverflow.com/questions/505397/built-in-wpf-ivalueconverters
Using the StringFormat property of a binding, you lose some of the flexibility you get when using a
converter, but in return, it's much simpler to use and doesn't involve the creation of a new class in a new
file.
The StringFormat property does exactly what the name implies: It formats the output string, simply by
calling the String.Format method. Sometimes an example says more than a thousand words, so before I hit
that word count, let's jump straight into an example:
<Window x:Class="WpfTutorialSamples.DataBinding.StringFormatSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="StringFormatSample" Height="150" Width="250"
Name="wnd">
<StackPanel Margin="10">
<TextBlock Text="{Binding ElementName=wnd, Path=ActualWidth,
StringFormat=Window width: {0:#,#.0}}" />
<TextBlock Text="{Binding ElementName=wnd, Path=ActualHeight,
StringFormat=Window height: {0:C}}" />
<TextBlock Text="{Binding Source={x:Static
system:DateTime.Now}, StringFormat=Date: {0:dddd, MMMM dd}}" />
<TextBlock Text="{Binding Source={x:Static
system:DateTime.Now}, StringFormat=Time: {0:HH:mm}}" />
</StackPanel>
</Window>
Also notice how I can include custom text in the StringFormat - this allows you to pre/post-fix the bound
value with text as you please. When referencing the actual value inside the format string, we surround it by
a set of curly braces, which includes two values: A reference to the value we want to format (value number
0, which is the first possible value) and the format string, separated by a colon.
For the last two values, we simply bind to the current date (DateTime.Now) and the output it first as a date,
in a specific format, and then as the time (hours and minutes), again using our own, pre-defined format.
You can read more about DateTime formatting here: http://msdn.microsoft.com/en-
us/library/az4se3k1.aspx
<Window x:Class="WpfTutorialSamples.DataBinding.StringFormatSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="StringFormatSample" Height="150" Width="250"
Name="wnd">
<WrapPanel Margin="10">
<TextBlock Text="Width: " />
<TextBlock Text="{Binding ElementName=wnd, Path=ActualWidth,
StringFormat={}{0:#,#.0}}" />
</WrapPanel>
</Window>
It's pretty simple: By combining the StringFormat property, which uses the D specifier (Long date pattern)
and the ConverterCulture property, we can output the bound values in accordance with a specific culture.
Pretty nifty!
<Window x:Class
="WpfTutorialSamples.DataBinding.DataBindingDebuggingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataBindingDebuggingSample" Height="100" Width="200">
<Grid Margin="10" Name="pnlMain">
<TextBlock Text="{Binding NonExistingProperty,
ElementName=pnlMain}" />
</Grid>
</Window>
This might seem a bit overwhelming, mainly because no linebreaks are used in this long message, but the
important part is this:
It tells you that you have tried to use a property called "NonExistingProperty" on an object of the type Grid,
with the name pnlMain. That's actually pretty concise and should help you correct the name of the property
or bind to the real object, if that's the problem.
<Window x:Class
="WpfTutorialSamples.DataBinding.DataBindingDebuggingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataBindingDebuggingSample" Height="100" Width="200">
<Grid Margin="10">
<TextBlock Text="{Binding Title}" />
</Grid>
</Window>
I'm trying to bind to the property "Title", but on which object? As stated in the article on data contexts, WPF
will use the DataContext property on the TextBlock here, which may be inherited down the control
hierarchy, but in this example, I forgot to assign a data context. This basically means that I'm trying to get a
property on a NULL object. WPF will gather that this might be a perfectly valid binding, but that the object
just hasn't been initialized yet, and therefore it won't complain about it. If you run this example and look in
the Output window, you won't see any binding errors.
However, for the cases where this is not the behavior that you're expecting, there is a way to force WPF
into telling you about all the binding problems it runs into. It can be done by setting the TraceLevel on the
PresentationTraceSources object, which can be found in the System.Diagnostics namespace:
<Window x:Class
="WpfTutorialSamples.DataBinding.DataBindingDebuggingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:diag="clr-
namespace:System.Diagnostics;assembly=WindowsBase"
Title="DataBindingDebuggingSample" Height="100" Width="200">
<Grid Margin="10">
<TextBlock Text="{Binding Title,
diag:PresentationTraceSources.TraceLevel=High}" />
</Grid>
</Window>
Notice that I have added a reference to the System.Diagnostics namespace in the top, and then used the
property on the binding. WPF will now give you loads of information about this specific binding in the
Output window:
By reading through the list, you can actually see the entire process that WPF goes through to try to find a
proper value for your TextBlock control. Several times you will see it being unable to find a proper
DataContext, and in the end, it uses the default {DependencyProperty.UnsetValue} which translates into an
empty string.
<Window x:Class
="WpfTutorialSamples.DataBinding.DataBindingDebuggingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:self="clr-namespace:WpfTutorialSamples.DataBinding"
Title="DataBindingDebuggingSample" Name="wnd" Height="100"
Width="200">
<Window.Resources>
<self:DebugDummyConverter x:Key="DebugDummyConverter" />
</Window.Resources>
<Grid Margin="10">
<TextBlock Text="{Binding Title, ElementName=wnd,
Converter={StaticResource DebugDummyConverter}}" />
</Grid>
</Window>
using System;
using System.Windows;
using System.Windows.Data;
using System.Diagnostics;
In the markup, we add a reference to our converter in the window resources and then we use it in our
binding. In a real world application, you should define the converter in a file of its own and then add the
reference to it in App.xaml, so that you may use it all over the application without having to create a new
reference to it in each window, but for this example, the above should do just fine.
If you run the example, you will see that the debugger breaks as soon as WPF tries to fetch the value for
the title of the window. You can now inspect the values given to the Convert() method, or even change
them before proceeding, using the standard debugging capabilities of Visual Studio.
If the debugger never breaks, it means that the converter is not used. This usually indicates that you have
For instance, if you have a typical interface with a main menu and a set of toolbars, an action like New or
Open might be available in the menu, on the toolbar, in a context menu (e.g. when right clicking in the main
application area) and from a keyboard shortcut like Ctrl+N and Ctrl+O.
Each of these actions needs to perform what is typically the exact same piece of code, so in a WinForms
application, you would have to define an event for each of them and then call a common function. With the
above example, that would lead to at least three event handlers and some code to handle the keyboard
shortcut. Not an ideal situation.
1.9.1.1. Commands
With WPF, Microsoft is trying to remedy that with a concept called commands. It allows you to define
actions in one place and then refer to them from all your user interface controls like menu items, toolbar
buttons and so on. WPF will also listen for keyboard shortcuts and pass them along to the proper
command, if any, making it the ideal way to offer keyboard shortcuts in an application.
Commands also solve another hassle when dealing with multiple entrances to the same function. In a
WinForms application, you would be responsible for writing code that could disable user interface elements
when the action was not available. For instance, if your application was able to use a clipboard command
like Cut, but only when text was selected, you would have to manually enable and disable the main menu
item, the toolbar button and the context menu item each time text selection changed.
With WPF commands, this is centralized. With one method you decide whether or not a given command
can be executed, and then WPF toggles all the subscribing interface elements on or off automatically. This
makes it so much easier to create a responsive and dynamic application!
1.9.1.4. Summary
Commands help you to respond to a common action from several different sources, using a single event
handler. It also makes it a lot easier to enable and disable user interface elements based on the current
availability and state. This was all theory, but in the next chapters we'll discuss how commands are used
and how you define your own custom commands.
<Window x:Class="WpfTutorialSamples.Commands.UsingCommandsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="UsingCommandsSample" Height="100" Width="200">
<Window.CommandBindings>
<CommandBinding Command="ApplicationCommands.New" Executed
="NewCommand_Executed" CanExecute="NewCommand_CanExecute" />
</Window.CommandBindings>
using System;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Input;
namespace WpfTutorialSamples.Commands
{
public partial class UsingCommandsSample : Window
{
public UsingCommandsSample()
{
InitializeComponent();
}
We define a command binding on the Window, by adding it to its CommandBindings collection. We specify
that Command that we wish to use (the New command from the ApplicationCommands), as well as two
event handlers. The visual interface consists of a single button, which we attach the command to using the
Command property.
In Code-behind, we handle the two events. The CanExecute handler, which WPF will call when the
application is idle to see if the specific command is currently available, is very simple for this example, as
we want this particular command to be available all the time. This is done by setting the CanExecute
property of the event arguments to true.
The Executed handler simply shows a message box when the command is invoked. If you run the sample
and press the button, you will see this message. A thing to notice is that this command has a default
keyboard shortcut defined, which you get as an added bonus. Instead of clicking the button, you can try to
press Ctrl+N on your keyboard - the result is the same.
A very common example of this is the toggling of buttons for using the Windows Clipboard, where you
want the Cut and Copy buttons to be enabled only when text is selected, and the Paste button to only be
enabled when text is present in the clipboard. This is exactly what we'll accomplish in this example:
using System;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Input;
namespace WpfTutorialSamples.Commands
{
public partial class CommandCanExecuteSample : Window
{
public CommandCanExecuteSample()
{
InitializeComponent();
}
So, we have this very simple interface with a couple of buttons and a TextBox control. The first button will
cut to the clipboard and the second one will paste from it.
In Code-behind, we have two events for each button: One that performs the actual action, which name
ends with _Executed, and then the CanExecute events. In each of them, you will see that I apply some
logic to decide whether or not the action can be executed and then assign it to the return value
CanExecute on the EventArgs.
WPF does this by handling the Executed and CanExecute events for you, when a text input control like the
TextBox has focus. You are free to override these events, which is basically what we did in the previous
example, but if you just want the basic behavior, you can let WPF connect the commands and the TextBox
control and do the work for you. Just see how much simpler this example is:
<Window x:Class
="WpfTutorialSamples.Commands.CommandsWithCommandTargetSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CommandsWithCommandTargetSample" Height="200" Width
="250">
<DockPanel>
<WrapPanel DockPanel.Dock="Top" Margin="3">
<Button Command="ApplicationCommands.Cut" CommandTarget="
{Binding ElementName=txtEditor}" Width="60">_Cut</Button>
<Button Command="ApplicationCommands.Paste" CommandTarget
="{Binding ElementName=txtEditor}" Width="60" Margin="3,0">_Paste</
Button>
</WrapPanel>
<TextBox AcceptsReturn="True" Name="txtEditor" />
</DockPanel>
</Window>
No Code-behind code needed for this example - WPF deals with all of it for us, but only because we want
to use these specific commands for this specific control. The TextBox does the work for us.
Notice how I use the CommandTarget properties on the buttons, to bind the commands to our TextBox
control. This is required in this particular example, because the WrapPanel doesn't handle focus the same
way e.g. a Toolbar or a Menu would, but it also makes pretty good sense to give the commands a target.
The easiest way to start implementing your own commands is to have a static class that will contain them.
Each command is then added to this class as static fields, allowing you to use them in your application.
Since WPF, for some strange reason, doesn't implement an Exit/Quit command, I decided to implement
one for our custom commands example. It looks like this:
<Window x:Class="WpfTutorialSamples.Commands.CustomCommandSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:self="clr-namespace:WpfTutorialSamples.Commands"
Title="CustomCommandSample" Height="150" Width="200">
<Window.CommandBindings>
<CommandBinding Command="self:CustomCommands.Exit" CanExecute
="ExitCommand_CanExecute" Executed="ExitCommand_Executed" />
</Window.CommandBindings>
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>
<Menu>
<MenuItem Header="File">
<MenuItem Command="self:CustomCommands.Exit" />
</MenuItem>
</Menu>
<StackPanel Grid.Row="1" HorizontalAlignment="Center"
VerticalAlignment="Center">
<Button Command="self:CustomCommands.Exit">Exit</Button>
</StackPanel>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Input;
All of this is just like the examples in the previous chapter, except for the fact that we're referencing the
command from our own code (using the "self" namespace defined in the top) instead of a built-in command.
In Code-behind, we respond to the two events for our command: One event just allows the command to
execute all the time, since that's usually true for an exit/quit command, and the other one calls the
Shutdown method that will terminate our application. All very simple.
As already explained, we implement our Exit command as a field on a static CustomCommands class.
There are several ways of defining and assigning properties on the commands, but I've chosen the more
compact approach (it would be even more compact if placed on the same line, but I've added line breaks
here for readability) where I assign all of it through the constructor. The parameters are the text/label of the
command, the name of the command, the owner type and then an InputGestureCollection, allowing me to
define a default shortcut for the command (Alt+F4).
1.9.3.1. Summary
Implementing custom WPF commands is almost as easy as consuming the built-in commands, and it
allows you to use commands for every purpose in your application. This makes it very easy to re-use
actions in several places, as shown in the example of this chapter.
The MessageBox is used by calling the static Show() method, which can take a range of different
parameters, to be able to look and behave the way you want it to. We'll be going through all the various
forms in this article, with each variation represented by the MessageBox.Show() line and a screenshot of
the result. In the end of the article, you can find a complete example which lets you test all the
variations.
In its simplest form, the MessageBox just takes a single parameter, which is the message to be displayed:
MessageBox.Show("Hello, world!");
You control which buttons are displayed by using a value from the MessageBoxButton enumeration - in
this case, a Yes, No and Cancel button is included. The following values, which should be self-explanatory,
can be used:
•
OK
•
OKCancel
•
YesNoCancel
•
YesNo
Now with multiple choices, you need a way to be able to see what the user chose, and fortunately, the
MessageBox.Show() method always returns a value from the MessageBoxResult enumeration that you
can use. Here's an example:
By checking the result value of the MessageBox.Show() method, you can now react to the user choice, as
seen in the code example as well as on the screenshots.
Using the MessageBoxImage enumeration, you can choose between a range of icons for different
situations. Here's the complete list:
•
Asterisk
•
Exclamation
•
Hand
•
Information
•
None
•
Question
•
Stop
•
Warning
The names should say a lot about how they look, but feel free to experiment with the various values or
have a look at this MSDN article, where each value is explained and even illustrated:
http://msdn.microsoft.com/en-us/library/system.windows.messageboximage.aspx
Notice on the screenshot how the "No" button is slightly elevated, to visually indicate that it is selected and
will be invoked if the Enter or Space button is pressed.
<Window x:Class="WpfTutorialSamples.Dialogs.MessageBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MessageBoxSample" Height="250" Width="300">
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center"
>
<StackPanel.Resources>
<Style TargetType="Button">
<Setter Property="Margin" Value="0,0,0,10" />
</Style>
</StackPanel.Resources>
<Button Name="btnSimpleMessageBox" Click
="btnSimpleMessageBox_Click">Simple MessageBox</Button>
<Button Name="btnMessageBoxWithTitle" Click
="btnMessageBoxWithTitle_Click">MessageBox with title</Button>
<Button Name="btnMessageBoxWithButtons" Click
using System;
using System.Windows;
namespace WpfTutorialSamples.Dialogs
{
public partial class MessageBoxSample : Window
{
public MessageBoxSample()
{
InitializeComponent();
}
For WPF, you will find standard dialogs for both opening and saving files in the Microsoft.Win32
namespace. In this article we'll focus on the OpenFileDialog class, which makes it very easy to display a
dialog for opening one or several files.
<Window x:Class="WpfTutorialSamples.Dialogs.OpenFileDialogSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="OpenFileDialogSample" Height="300" Width="300">
<DockPanel Margin="10">
<WrapPanel HorizontalAlignment="Center" DockPanel.Dock="Top"
Margin="0,0,0,10">
<Button Name="btnOpenFile" Click="btnOpenFile_Click">
Open file</Button>
</WrapPanel>
<TextBox Name="txtEditor" />
</DockPanel>
</Window>
using System;
using System.IO;
using System.Windows;
using Microsoft.Win32;
namespace WpfTutorialSamples.Dialogs
{
public partial class OpenFileDialogSample : Window
{
public OpenFileDialogSample()
{
InitializeComponent();
}
Once you click the Open file button, the OpenFileDialog will be instantiated and shown. Depending on
which version of Windows you're using and the theme selected, it will look something like this:
The ShowDialog() will return a nullable boolean value, meaning that it can be either false, true or null. If the
user selects a file and presses "Open", the result is True, and in that case, we try to load the file into the
TextBox control. We get the complete path of the selected file by using the FileName property of the
OpenFileDialog.
1.10.2.2. Filter
Normally when you want your user to open a file in your application, you want to limit it to one or a couple
of file types. For instance, Word mostly opens Word file (with the extension .doc or .docx) and Notepad
You can specify a filter for your OpenFileDialog to indicate to the user which types of file they should be
opening in your application, as well as limiting the files shown for a better overview. This is done with the
Filter property, which we can add to the above example, right after initializing the dialog, like this:
Notice how the dialog now has a combo box for selecting the file types, and that the files shown are limited
to ones with the extension(s) specified by the selected file type.
The format for specifying the filter might look a bit strange at first sight, but it works by specifying a human-
readable version of the desired file extension(s) and then one for the computer to easily parse, separated
with a pipe (|) character. If you want more than one file type, as we do in the above example, each set of
So to sum up, the following part means that we want the file type to be named "Text files (*.txt)" (the
extension in the parenthesis is a courtesy to the user, so they know which extension(s) are included) and
the second part tells the dialog to show files with a .txt extension:
Each file type can of course have multiple extensions. For instance, image files could be specified as both
JPEG and PNG files, like this:
Simply separate each extension with a semicolon in the second part (the one for the computer) - in the first
part, you can format it the way you want to, but most developers seem to use the same notation for both
parts, as seen in the example above.
openFileDialog.InitialDirectory = @"c:\temp\";
If you want to use one of the special folders on Windows, e.g. the Desktop, My Documents or the Program
Files directory, you have to take special care, since these may vary from each version of Windows and also
be dependent on which user is logged in. The .NET framework can help you though, just use the
Environment class and its members for dealing with special folders:
openFileDialog.InitialDirectory =
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
In this case, I get the path for the My Documents folder, but have a look at the SpecialFolder enumeration -
it contains values for a lot of interesting paths. For a full list, please see this MSDN article.
<Window x:Class
="WpfTutorialSamples.Dialogs.OpenFileDialogMultipleFilesSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="OpenFileDialogMultipleFilesSample" Height="300" Width
="300">
<DockPanel Margin="10">
<WrapPanel HorizontalAlignment="Center" DockPanel.Dock="Top"
Margin="0,0,0,10">
<Button Name="btnOpenFile" Click="btnOpenFiles_Click">
Open files</Button>
</WrapPanel>
<ListBox Name="lbFiles" />
</DockPanel>
</Window>
namespace WpfTutorialSamples.Dialogs
{
public partial class OpenFileDialogMultipleFilesSample : Window
{
public OpenFileDialogMultipleFilesSample()
{
InitializeComponent();
}
1.10.2.5. Summary
As you can see, using the OpenFileDialog in WPF is very easy and really takes care of a lot of work for
you. Please be aware that to reduce the amount of code lines, no exception handling is done in these
examples. When working with files and doing IO tasks in general, you should always look out for
exceptions, as they can easily occur due to a locked file, non-existing path or related problems.
<Window x:Class="WpfTutorialSamples.Dialogs.SaveFileDialogSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SaveFileDialogSample" Height="300" Width="300">
<DockPanel Margin="10">
<WrapPanel HorizontalAlignment="Center" DockPanel.Dock="Top"
Margin="0,0,0,10">
<Button Name="btnSaveFile" Click="btnSaveFile_Click">
Save file</Button>
</WrapPanel>
<TextBox Name="txtEditor" TextWrapping="Wrap" AcceptsReturn
="True" ScrollViewer.VerticalScrollBarVisibility="Auto" />
</DockPanel>
</Window>
using System;
using System.IO;
using System.Windows;
using Microsoft.Win32;
namespace WpfTutorialSamples.Dialogs
{
public partial class SaveFileDialogSample : Window
{
public SaveFileDialogSample()
{
InitializeComponent();
}
As you can see, it's mostly about instantiating the SaveFileDialog and then calling the ShowDialog()
method. If it returns true, we use the FileName property (which will contain the selected path as well as the
user entered file name) as the path to write our contents to.
If you click the save button, you should see a dialog like this, depending on the version of Windows you're
using:
1.10.3.2. Filter
As you can see from the first example, I manually added a .txt extension to my desired filename, mainly
because the "Save as type" combo box is empty. Just like for the OpenFileDialog, this box is controlled
through the Filter property, and it's also used in the exact same way.
For more details about the format of the Filter property, please see the previous article on
the OpenFileDialog, where it's explained in details.
With a filter like the above, the resulting SaveFileDialog will look like this instead:
With that in place, you can write filenames without specifying the extension - it will be taken from the
selected file type in the filter combo box instead. This also indicates to the user which file formats your
application supports, which is of course important.
saveFileDialog.InitialDirectory = @"c:\temp\";
If you want to use one of the special folders on Windows, e.g. the Desktop, My Documents or the Program
Files directory, you have to take special care, since these may vary from each version of Windows and also
depend on which user is logged in. The .NET framework can help you though, just use the Environment
class and its members for dealing with special folders:
saveFileDialog.InitialDirectory =
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
In this case, I get the path for the My Documents folder, but have a look at the SpecialFolder enumeration -
it contains values for a lot of interesting paths. For a full list, please see this MSDN article.
1.10.3.4. Options
AddExtension - defaults to true and determines if the SaveFileDialog should automatically append an
extension to the filename, if the user omits it. The extension will be based on the selected filter, unless
that's not possible, in which case it will fall back to the DefaultExt property (if specified). If you want your
application to be able to save files without file extensions, you may have to disable this option.
OverwritePrompt - defaults to true and determines if the SaveFileDialog should ask for a confirmation if
the user enters a file name which will result in an existing file being overwritten. You will normally want to
leave this option enabled except in very special situations.
Title - you may override this property if you want a custom title on your dialog. It defaults to "Save As" or
the localized equivalent and the property is also valid for the OpenFileDialog.
ValidateNames - defaults to true and unless it's disabled, it will ensure that the user enters only valid
Windows file names before allowing the user to continue.
This can be a real problem for WPF developers, since re-implementing these dialogs would be a huge
task. Fortunately, WPF and WinForms can be mixed, simply by referencing the System.Windows.Forms
assembly, but since WPF uses different base types for both colors and dialogs, this is not always a viable
solution. It is however an easy solution if you just need the FolderBrowserDialog, since it only deals with
folder paths as simple strings, but some purists would argue that mixing WPF and WinForms is never the
way to go.
A better way to go, if you don't want to reinvent the wheel yourself, might be to use some of the work
created by other developers. Here are a couple of links for article which offers a solution to some of the
missing dialogs:
In the end, you should choose the solution which fits the requirements of your application best.
However, there are a few things that you should remember when creating dialogs, to ensure that your
application acts like other Windows applications. In this article, we'll create a very simple dialog to ask the
user a question and then return the answer, while discussing the various good practices that you should
follow.
<Window x:Class="WpfTutorialSamples.Dialogs.InputDialogSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Input" SizeToContent="WidthAndHeight"
WindowStartupLocation="CenterScreen"
ContentRendered="Window_ContentRendered">
<Grid Margin="15">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<Image Source
="/WpfTutorialSamples;component/Images/question32.png" Width="32" Height
="32" Grid.RowSpan="2" Margin="20,0" />
using System;
using System.Windows;
namespace WpfTutorialSamples.Dialogs
{
public partial class InputDialogSample : Window
{
public InputDialogSample(string question, string defaultAnswer
= "")
{
InitializeComponent();
lblQuestion.Content = question;
txtAnswer.Text = defaultAnswer;
}
The code is pretty simple, but here are the things that you should pay special attention to:
1.10.5.2. XAML
In the XAML part, I've used a Grid for layout of the controls - nothing fancy here. I've removed the Width
and Height properties of the Window and instead set it to automatically resize to match the content - this
makes sense in a dialog, so you don't have to fine tune the size to make everything look alright. Instead,
use margins and minimum sizes to ensure that things look the way you want them to, while still allowing the
user to resize the dialog.
Another property which I've changed on the Window is the WindowStartupLocation property. For a
dialog like this, and probably for most other non-main windows, you should change this value to
CenterScreen or CenterOwner, to change the default behavior where your window will appear in a position
decided by Windows, unless you manually specify Top and Left properties for it.
Also pay special attention to the two properties I've used on the dialog buttons: IsCancel and IsDefault.
IsCancel tells WPF that if the user clicks this button, the DialogResult of the Window should be set to false
which will also close the window. This also ensures that the user can press the Esc key on their keyboard
to close the window, something that should always be possible in a Windows dialog.
The IsDefault property gives focus to the Ok button and also ensures that if the user presses the Enter
key on their keyboard, this button is activated. An event handler is needed to set the DialogResult for this
though, as described later.
1.10.5.3. Code-behind
In Code-behind, I changed the constructor to take two parameters, with one being optional. This allows us
to place the question and the default answer, if provided, into the designated UI controls.
To give focus to the TextBox upon showing the dialog, I've subscribed to the ContentRendered event,
where I select all the text in the control and then give focus. If I just wanted to give focus, I could have use
the FocusManager.FocusedElement attached property on the Window, but in this case, I also want to
select the text, to allow the user to instantly overwrite the answer provided by default (if any).
A last detail is the Answer property which I've implemented. It simply gives access to the entered value of
the TextBox control, but it's good practice to provide a property with the return value(s) of the dialog,
instead of directly accessing controls from outside the window. This also allows you to influence the return
value before returning it, if needed.
<Window x:Class="WpfTutorialSamples.Dialogs.InputDialogAppSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="InputDialogAppSample" Height="150" Width="300">
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center"
>
<TextBlock>Hello, world. My name is:</TextBlock>
<TextBlock Name="lblName" Margin="0,10" TextAlignment="Center"
FontWeight="Bold">[No name entered]</TextBlock>
<Button Name="btnEnterName" Click="btnEnterName_Click">Enter
name...</Button>
</StackPanel>
</Window>
using System;
using System.Windows;
namespace WpfTutorialSamples.Dialogs
{
public partial class InputDialogAppSample : Window
There's nothing special to it - just a couple of TextBlock controls and a Button for invoking the dialog. In the
Click event handler, we instantiate the InputDialogSample window, providing a question and a default
answer, and then we use the ShowDialog() method to show it - you should always use ShowDialog()
method and not just Show() for a modal dialog like this.
If the result of the dialog is true, meaning that the user has activated the Ok button either by clicking it or
pressing Enter, the result is assigned to the name Label. That's all there is to it!
WPF comes with a fine control for creating menus called... Menu. Adding items to it is very simple - you
simply add MenuItem elements to it, and each MenuItem can have a range of sub-items, allowing you to
create hierarchical menus as you know them from a lot of Windows applications. Let's jump straight to an
example where we use the Menu:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.MenuSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MenuSample" Height="200" Width="200">
<DockPanel>
<Menu DockPanel.Dock="Top">
<MenuItem Header="_File">
<MenuItem Header="_New" />
<MenuItem Header="_Open" />
<MenuItem Header="_Save" />
<Separator />
<MenuItem Header="_Exit" />
</MenuItem>
</Menu>
<TextBox AcceptsReturn="True" />
</DockPanel>
</Window>
As in most Windows applications, my menu is placed in the top of the window, but in keeping with the
enormous flexibility of WPF, you can actually place a Menu control wherever you like, and in any width or
height that you may desire.
I have defined a single top-level item, with 4 child items and a separator. I use the Header property to
define the label of the item, and you should notice the underscore before the first character of each label. It
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.MenuIconCheckableSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MenuIconCheckableSample" Height="150" Width="300">
<DockPanel>
<Menu DockPanel.Dock="Top">
<MenuItem Header="_File">
<MenuItem Header="_Exit" />
</MenuItem>
<MenuItem Header="_Tools">
<MenuItem Header="_Manage users">
<MenuItem.Icon>
<Image Source
="/WpfTutorialSamples;component/Images/user.png" />
</MenuItem.Icon>
</MenuItem>
<MenuItem Header="_Show groups" IsCheckable="True"
For this example I've created a secondary top-level item, where I've added two items: One with an icon
defined, using the Icon property with a standard Image control inside of it, and one where we use the
IsCheckable property to allow the user to check and uncheck the item. I even used the IsChecked
property to have it checked by default. From Code-behind, this is the same property that you can read to
know whether a given menu item is checked or not.
In Code-behind you will then need to implement the mnuNew_Click method, like this:
This will suffice for the more simple applications, or when prototyping something, but the WPF way is to
use a Command for this.
First of all, they ensure that you can have the same action on a toolbar, a menu and even a context menu,
without having to implement the same code in multiple places. They also make the handling of keyboard
shortcuts a whole lot easier, because unlike with WinForms, WPF is not listening for keyboard shortcuts
automatically if you assign them to e.g. a menu item - you will have to do that manually.
However, when using commands, WPF is all ears and will respond to keyboard shortcuts automatically.
The text (Header) of the menu item is also set automatically (although you can overwrite it if needed), and
so is the InputGestureText, which shows the user which keyboard shortcut can be used to invoke the
specific menu item. Let's jump straight to an example of combining the Menu with WPF commands:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.MenuWithCommandsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MenuWithCommandsSample" Height="200" Width="300">
<Window.CommandBindings>
<CommandBinding Command="New" CanExecute
="NewCommand_CanExecute" Executed="NewCommand_Executed" />
</Window.CommandBindings>
<DockPanel>
<Menu DockPanel.Dock="Top">
<MenuItem Header="_File">
<MenuItem Command="New" />
<Separator />
<MenuItem Header="_Exit" />
</MenuItem>
<MenuItem Header="_Edit">
<MenuItem Command="Cut" />
<MenuItem Command="Copy" />
<MenuItem Command="Paste" />
</MenuItem>
</Menu>
using System;
namespace WpfTutorialSamples.Common_interface_controls
{
public partial class MenuWithCommandsSample : Window
{
public MenuWithCommandsSample()
{
InitializeComponent();
}
It might not be completely obvious, but by using commands, we just got a whole bunch of things for free:
Keyboard shortcuts, text and InputGestureText on the items and WPF automatically enables/disables the
items depending on the active control and its state. In this case, Cut and Copy are disabled because no
text is selected, but Paste is enabled, because my clipboard is not empty!
1.11.1.4. Summary
Working with the WPF Menu control is both easy and fast, making it simple to create even complex menu
hierarchies, and when combining it with WPF commands, you get so much functionality for free.
WPF comes with a ContextMenu control and because it's almost always tied to a specific control, that's
also usually how you add it to the interface. This is done through the ContextProperty, which all controls
exposes (it comes from the FrameworkElement which most WPF controls inherits from). Consider the next
example to see how it's done:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ContextMenuSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ContextMenuSample" Height="250" Width="250">
<Grid>
<Button Content="Right-click me!" VerticalAlignment="Center"
HorizontalAlignment="Center">
<Button.ContextMenu>
<ContextMenu>
<MenuItem Header="Menu item 1" />
<MenuItem Header="Menu item 2" />
<Separator />
<MenuItem Header="Menu item 3" />
</ContextMenu>
</Button.ContextMenu>
</Button>
</Grid>
</Window>
If you've already read the chapter on the regular menu, you will soon realize that the ContextMenu works
exactly the same way, and no wonder, since they both inherit the MenuBase class. Just like we saw in the
examples on using the regular Menu, you can of course add Click events to these items to handle when the
user clicks on them, but a more WPF-suitable way is to use Commands.
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ContextMenuWithCommandsSa
mple"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ContextMenuWithCommandsSample" Height="200" Width="250"
>
<StackPanel Margin="10">
<TextBox Text="Right-click here for context menu!">
<TextBox.ContextMenu>
<ContextMenu>
<MenuItem Command="Cut">
<MenuItem.Icon>
<Image Source
="/WpfTutorialSamples;component/Images/cut.png" />
</MenuItem.Icon>
</MenuItem>
<MenuItem Command="Copy">
<MenuItem.Icon>
<Image Source
="/WpfTutorialSamples;component/Images/copy.png" />
</MenuItem.Icon>
</MenuItem>
<MenuItem Command="Paste">
Try running the example and see for yourself how much functionality we get for free by assigning
commands to the items. Also notice how fairly simple it is to use icons on the menu items of the
ContextMenu.
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ContextMenuManuallyInvoke
dSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ContextMenuManuallyInvokedSample" Height="250" Width
="250">
using System;
using System.Windows;
using System.Windows.Controls;
namespace WpfTutorialSamples.Common_interface_controls
{
public partial class ContextMenuManuallyInvokedSample : Window
{
public ContextMenuManuallyInvokedSample()
{
InitializeComponent();
}
The first thing you should notice is that I've moved the ContextMenu away from the button. Instead, I've
added it as a resource of the Window, to make it available from all everywhere within the Window. This also
makes it a lot easier to find when we need to show it.
A WPF ToolBar is usually placed inside of a ToolBarTray control. The ToolBarTray will handle stuff like
placement and sizing, and you can have multiple ToolBar controls inside of the ToolBarTray element. Let's
try a pretty basic example, to see what it all looks like:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ToolbarSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolbarSample" Height="200" Width="300">
<Window.CommandBindings>
<CommandBinding Command="New" CanExecute
="CommonCommandBinding_CanExecute" />
<CommandBinding Command="Open" CanExecute
="CommonCommandBinding_CanExecute" />
<CommandBinding Command="Save" CanExecute
="CommonCommandBinding_CanExecute" />
</Window.CommandBindings>
<DockPanel>
<ToolBarTray DockPanel.Dock="Top">
<ToolBar>
<Button Command="New" Content="New" />
<Button Command="Open" Content="Open" />
<Button Command="Save" Content="Save" />
</ToolBar>
<ToolBar>
<Button Command="Cut" Content="Cut" />
<Button Command="Copy" Content="Copy" />
<Button Command="Paste" Content="Paste" />
</ToolBar>
</ToolBarTray>
<TextBox AcceptsReturn="True" />
</DockPanel>
</Window>
namespace WpfTutorialSamples.Common_interface_controls
{
public partial class ToolbarSample : Window
{
public ToolbarSample()
{
InitializeComponent();
}
Notice how I use commands for all the buttons. We discussed this in the previous chapter and using
commands definitely gives us some advantages. Take a look at the Menu chapter, or the articles on
commands, for more information.
In this example, I add a ToolBarTray to the top of the screen, and inside of it, two ToolBar controls. Each
contains some buttons and we use commands to give them their behavior. In Code-behind, I make sure to
handle the CanExecute event of the first three buttons, since that's not done automatically by WPF,
contrary to the Cut, Copy and Paste commands, which WPF is capable of fully handling for us.
1.11.3.1. Images
While text on the toolbar buttons is perfectly okay, the normal approach is to have icons or at least a
combination of an icon and a piece of text. Because WPF uses regular Button controls, adding icons to the
toolbar items is very easy. Just have a look at this next example, where we do both:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ToolbarIconSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolbarIconSample" Height="200" Width="300">
<DockPanel>
<ToolBarTray DockPanel.Dock="Top">
<ToolBar>
<Button Command="Cut" ToolTip="Cut selection to
Windows Clipboard.">
<Image Source
="/WpfTutorialSamples;component/Images/cut.png" />
</Button>
<Button Command="Copy" ToolTip="Copy selection to
Windows Clipboard.">
<Image Source
="/WpfTutorialSamples;component/Images/copy.png" />
</Button>
<Button Command="Paste" ToolTip="Paste from Windows
Clipboard.">
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/paste.png" />
<TextBlock Margin="3,0,0,0">Paste</
TextBlock>
</StackPanel>
</Button>
</ToolBar>
</ToolBarTray>
<TextBox AcceptsReturn="True" />
</DockPanel>
By specifying an Image control as the Content of the first two buttons, they will be icon based instead of
text based. On the third button, I combine an Image control and a TextBlock control inside of a
StackPanel, to achieve both icon and text on the button, a commonly used technique for buttons which are
extra important or with a less obvious icon.
Notice how I've used the ToolTip property on each of the buttons, to add an explanatory text. This is
especially important for those buttons with only an icon, because the purpose of the button might not be
clear from only looking at the icon. With the ToolTip property, the user can hover the mouse over the button
to get a description of what it does, as demonstrated on the screenshot.
1.11.3.2. Overflow
As already mentioned, a very good reason for using the ToolBar control instead of just a panel of buttons,
is the automatic overflow handling. It means that if there's no longer enough room to show all of the buttons
on the toolbar, WPF will put them in a menu accessible by clicking on the arrow to the right of the toolbar.
You can see how it works on this screenshot, which shows the first example, but with a smaller window,
thereby leaving less space for the toolbars:
This is where the attached property ToolBar.OverflowMode comes into play. The default value is
IfNeeded, which simply means that a toolbar item is put in the overflow menu if there's not enough room for
it. You may use Always or Never instead, which does exactly what the names imply: Puts the item in the
overflow menu all the time or prevents the item from ever being moved to the overflow menu. Here's an
example on how to assign this property:
<ToolBar>
<Button Command="Cut" Content="Cut" ToolBar.OverflowMode="Always"
/>
<Button Command="Copy" Content="Copy" ToolBar.OverflowMode
="AsNeeded" />
<Button Command="Paste" Content="Paste" ToolBar.OverflowMode
="Never" />
</ToolBar>
1.11.3.3. Position
While the most common position for the toolbar is indeed in the top of the screen, toolbars can also be
found in the bottom of the application window or even on the sides. The WPF ToolBar of course supports
all of this, and while the bottom placed toolbar is merely a matter of docking to the bottom of the panel
instead of the top, a vertical toolbar requires the use of the Orientation property of the ToolBar tray. Allow
me to demonstrate with an example:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ToolbarPositionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolbarPositionSample" Height="200" Width="300">
<DockPanel>
<ToolBarTray DockPanel.Dock="Top">
<ToolBar>
<Button Command="Cut" ToolTip="Cut selection to
Windows Clipboard.">
<Image Source
="/WpfTutorialSamples;component/Images/cut.png" />
</Button>
The trick here lies in the combination of the DockPanel.Dock property, that puts the ToolBarTray to the
right of the application, and the Orientation property, that changes the orientation from horizontal to
Another thing introduced in this example is the Separator element, which simply creates a separator
between two sets of toolbar items. As you can see from the example, it's very easy to use!
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.ToolbarCustomControlsSamp
le"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ToolbarCustomControlsSample" Height="200" Width="300">
<DockPanel>
<ToolBarTray DockPanel.Dock="Top">
<ToolBar>
<Button Command="Cut" ToolTip="Cut selection to
Windows Clipboard.">
<Image Source
="/WpfTutorialSamples;component/Images/cut.png" />
</Button>
<Button Command="Copy" ToolTip="Copy selection to
Windows Clipboard.">
1.11.3.5. Summary
Creating interfaces with toolbars is very easy in WPF, with the flexible ToolBar control. You can do things
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.StatusBarSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StatusBarSample" Height="150" Width="300">
<DockPanel>
<StatusBar DockPanel.Dock="Bottom">
<StatusBarItem>
<TextBlock Name="lblCursorPosition" />
</StatusBarItem>
</StatusBar>
<TextBox AcceptsReturn="True" Name="txtEditor"
SelectionChanged="txtEditor_SelectionChanged" />
</DockPanel>
</Window>
using System;
using System.Windows;
namespace WpfTutorialSamples.Common_interface_controls
{
public partial class StatusBarSample : Window
{
public StatusBarSample()
{
InitializeComponent();
}
It's all very simple - a TextBlock control that shows the current cursor position, just like in pretty much any
other application that allows you to edit text. In this very basic form, the StatusBar could just as easily have
been a panel with a set of controls on it, but the real advantage of the StatusBar comes when we need to
divide it into several areas of information.
We'll divide the Grid into three areas, with the left and right one having a fixed width and the middle
column automatically taking up the remaining space. We'll also add columns in between for Separator
controls. Here's how it looks now:
<Window x:Class
="WpfTutorialSamples.Common_interface_controls.StatusBarAdvancedSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StatusBarAdvancedSample" Height="150" Width="400">
using System;
using System.Windows;
namespace WpfTutorialSamples.Common_interface_controls
{
public partial class StatusBarAdvancedSample : Window
{
public StatusBarAdvancedSample()
{
As you can see, I've added a bit of sample information, like the fake filename in the middle column and the
progress bar to the right, showing a static value for now. You could easily make this work for real though,
and it gives a pretty good idea on what you can do with the StatusBar control.
1.11.4.2. Summary
Once again, WPF makes it easy to get standard Windows functionality, in this case the StatusBar,
integrated into your applications.
You can even place other controls than the ones used in these examples, like buttons, combo boxes and
so on, but please be aware that since the StatusBar doesn't apply any special rendering to these controls
when hosting them, it might not look as you would expect it to for controls in a status bar. This can be
handled with custom styling if you need it though, a subject discussed elsewhere in this tutorial.
WPF doesn't come with a built-in Ribbon control, but Microsoft has released one that you can download
and use for free, as long as you promise to follow their implementation guide when using it. You can read
much more about it at MSDN, where you'll also find a download link for the Ribbon control.
1.11.5.1. Summary
You can download and use a Microsoft created Ribbon control, but it's not yet a part of the .NET
framework by default. Once it becomes an integrated part of the framework, we'll dig into it here at this
tutorial. In the meantime, if you're looking for a more complete Ribbon implementation, you might want to
look at some 3rd party alternatives - there are plenty of them, from some of the big WPF control vendors.
The FlowDocument does indeed render rich text, and that even includes images, lists and tables, and
elements can be floated, adjusted and so on, and using a FlowDocument, you can specify rich text in
design-time as if it were HTML (thanks to XAML) and have it rendered directly in your WPF application.
The FlowDocument doesn't stand alone. Instead, it uses one of several built-in wrappers, which controls
how the FlowDocument is laid out and whether the content can be edited by the user or not. WPF includes
three controls for rendering a FlowDocument in read-only mode, which all has easy support for zooming
and printing:
FlowDocumentScrollViewer - the simplest wrapper around a FlowDocument, which simply displays the
document as one long document of text which you can scroll in.
FlowDocumentPageViewer - this wrapper will automatically split your document into pages, which the
user can navigate back and forth between.
The FlowDocument is normally read-only, but put it inside of a RichTextBox control (described later in this
tutorial) and you can now edit the text, much like in real word processors like Microsoft Word.
Read on through the next chapters, where we'll discuss all the wrappers that you can use with a
FlowDocument, both read-only and editable. After that, we'll look into all of the possibilities you have when
creating rich documents using the FlowDocument, including tables, lists, images and much more.
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentScrollViewerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentScrollViewerSample" Height="200" Width
="300">
<Grid>
<FlowDocumentScrollViewer>
<FlowDocument>
<Paragraph FontSize="36">Hello, world!</Paragraph>
<Paragraph FontStyle="Italic" TextAlignment="Left"
FontSize="14" Foreground="Gray">The ultimate programming greeting!</
Paragraph>
</FlowDocument>
</FlowDocumentScrollViewer>
</Grid>
</Window>
Notice how easy it was to specify the text, using simple markup tags, in this case the Paragraph tag. Now
you might argue that this could have been achieved with a couple of TextBlock controls, and you would be
absolutely right, but even with an extremely basic example like this, you get a bit of added functionality for
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentScrollViewerZoomSamp
le"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentScrollViewerZoomSample" Height="180" Width
="300">
<Grid>
<FlowDocumentScrollViewer IsToolBarVisible="True" Zoom="80"
ScrollViewer.VerticalScrollBarVisibility="Auto">
<FlowDocument>
<Paragraph FontSize="36">Hello, world!</Paragraph>
<Paragraph FontStyle="Italic" TextAlignment="Left"
FontSize="14" Foreground="Gray">The ultimate programming greeting!</
Paragraph>
</FlowDocument>
</FlowDocumentScrollViewer>
Now the user can control the zoom level using the slider and the buttons in the toolbar below the
document. Notice also that we changed the default zoom level, using the Zoom property - it defines the
zoom level in percentages, so in this case, the text is zoomed out to 80% by default.
The last thing I changed in this example, in comparison to the first one, is the use of the
ScrollViewer.VerticalScrollBarVisibility property. By setting it to Auto, the scrollbars will be invisible until
the content actually goes beyond the available space, which is usually what you want.
However, in many situations, justified text makes sense, but it can result in some very bad layout, with very
excessive amounts of whitespace on lines where a linebreak is inserted right before a very long word.
The following example will illustrate that, as well as provide a solution that will help remedy the problem. By
using the IsOptimalParagraphEnabled property in combination with the IsHyphenationEnabled property,
you will give WPF a better chance of laying out the text in the best possible way.
IsOptimalParagraphEnabled allows WPF to look ahead in your text, to see if it would make more sense to
break the text in a different position than right at the moment where it runs out of space.
IsHyphenationEnabled allows WPF to split your words with a hyphen, if it would allow for a more natural
layout of the text.
In the next example, I've rendered the same text twice - one without these properties, and one with. The
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentTextAlignmentSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentTextAlignmentSample" Height="400" Width
="330">
<StackPanel>
<FlowDocumentScrollViewer
ScrollViewer.VerticalScrollBarVisibility="Auto">
<FlowDocument>
<Paragraph FontStyle="Italic" FontSize="14"
Foreground="Gray">
By setting the
<Bold>IsOptimalParagraphEnabled</Bold> property
to true,
you will allow WPF to look ahead on the lines
to come, before deciding
where to break. This will usually result in a
more pleasant reading
experience. It works especially well in
combination with the
<Bold>IsHyphenationEnabled</Bold> property.
</Paragraph>
</FlowDocument>
</FlowDocumentScrollViewer>
<FlowDocumentScrollViewer
ScrollViewer.VerticalScrollBarVisibility="Auto">
<FlowDocument IsOptimalParagraphEnabled="True"
IsHyphenationEnabled="True">
<Paragraph FontStyle="Italic" FontSize="14"
Foreground="Gray">
By setting the <Bold>IsOptimalParagraphEnabled
</Bold> property to true,
you will allow WPF to look ahead on the lines
to come, before deciding
where to break. This will usually result in a
more pleasant reading
experience. It works especially well in
IsOptimalParagraphEnabled is not enabled by default because it does require a bit more CPU power when
rendering the text, especially if the window is frequently resized. For most situations this shouldn't be a
problem though.
If you have a lot of FlowDocument instances in your application and you prefer this optimal rendering
method, you can enable it on all of your FlowDocument instances by specifying a global style that enables
it, in your App.xaml. Here's an example:
<Application x:Class="WpfTutorialSamples.App"
We'll start off with a simple example, where we can see how the FlowDocumentPageViewer control
handles our Lorem Ipsum test text:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentPageViewerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentPageViewerSample" Height="300" Width="300">
<Grid>
<FlowDocumentPageViewer>
<FlowDocument>
<Paragraph>Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Fusce faucibus odio arcu, luctus vestibulum tortor
congue in. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Fusce nec lacinia neque. Donec malesuada, ligula non vestibulum cursus,
urna purus pellentesque orci, aliquet accumsan dui velit ac justo.
Phasellus sagittis ligula in leo dapibus, vel vestibulum felis mattis.
Fusce vitae auctor nibh. Ut sit amet fringilla turpis. Aenean tincidunt
feugiat sapien, quis scelerisque enim pretium commodo. Mauris fermentum
posuere nulla, vitae fermentum quam malesuada in. Cras ultrices bibendum
nulla eu mollis. Sed accumsan pretium magna, non sodales velit viverra
id. Sed eu elit sit amet sem ullamcorper rhoncus.</Paragraph>
<Paragraph>Nulla vitae suscipit tellus. Nunc sit
amet tortor fermentum, sollicitudin enim cursus, sagittis lacus.
Pellentesque tincidunt massa nisl, nec tempor nulla consequat a. Proin
pharetra neque vel dolor congue, at condimentum arcu varius. Sed vel
luctus enim. Curabitur eleifend dui et arcu faucibus, sit amet vulputate
libero suscipit. Vestibulum ultrices nisi id metus ultrices, eu
ultricies ligula rutrum. Phasellus rhoncus aliquam pretium. Quisque in
nunc erat. Etiam mollis turpis cursus, sagittis felis vel, dignissim
risus. Ut at est nec tellus lobortis venenatis. Fusce elit mi, gravida
sed tortor at, faucibus interdum felis. Phasellus porttitor dolor in
nunc pellentesque, eu hendrerit nulla porta. Vestibulum cursus placerat
Notice how the long text is cut off, and in the bottom, you can navigate between pages. This is not all that
the FlowDocumentPageViewer will do for you though - just look what happens when we make the window
wider:
Instead of just stretching the text indefinitely, the FlowDocumentPageViewer now divides your text up into
columns, to prevent lines from becoming too long. Besides looking good, this also increases the readability,
as texts with very long lines are harder to read. The page count is of course automatically adjusted,
bringing the amount of pages down from 5 to 2.
The FlowDocument class has a range of properties that will allow you to control how and when they are
used. Using them is simple, but a complete example goes beyond the scope of this tutorial. Instead, have a
look at this MSDN article, where several properties are used in a nice example: How to: Use
FlowDocument Column-Separating Attributes.
1.12.3.1. Searching
As you're about to see in the next chapter, the FlowDocumentReader wrapper supports searching right out
All three viewers support the Ctrl+F keyboard shortcut for initiating a search, but if you want this to be
accessible from e.g. a button as well, you just have to call the Find() method. Here's an example:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentSearchSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentSearchSample" Height="300" Width="580">
<DockPanel>
<WrapPanel DockPanel.Dock="Top">
<Button Name="btnSearch" Click="btnSearch_Click">Search</
Button>
</WrapPanel>
<FlowDocumentPageViewer Name="fdViewer">
<FlowDocument>
<Paragraph>Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Fusce faucibus odio arcu, luctus vestibulum tortor
congue in. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Fusce nec lacinia neque. Donec malesuada, ligula non vestibulum cursus,
using System;
using System.Windows;
namespace WpfTutorialSamples.Rich_text_controls
{
public partial class FlowDocumentSearchSample : Window
{
public FlowDocumentSearchSample()
{
InitializeComponent();
}
Simply press our dedicated Search button or the keyboard shortcut (Ctrl+F) and you have search
functionality in the FlowDocumentPageViewer. As mentioned, this works for both
FlowDocumentScrollViewer and FlowDocumentPageViewer (FlowDocumentPageReader has a search
button by default), but make sure that the search box has enough horizontal room on the toolbar -
otherwise you won't see it when you invoke the Find() command!
All of this functionality also makes the FlowDocumentReader the heaviest of the three read-only wrappers,
but this should hardly be an issue with most regularly sized documents. Here's an example of how the
FlowDocumentReader might look:
This screenshot is taken in the page-based view, which is the default. You can switch between the view
modes using the buttons to the left of the zoom controls. In the left part of the toolbar, you have the controls
for searching through the document, as I have done here on the screenshot.
Here's the code that will give you the above result:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.FlowDocumentReaderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FlowDocumentReaderSample" Height="250" Width="550">
<Grid>
<FlowDocumentReader>
<FlowDocument>
This markup will result in a window as seen on the screenshot above. Here's a screenshot where we've
gone into the two-page mode as well as reduced the zoom a bit:
The FlowDocumentReader has a range of properties that can help you in controlling how it works. Here's
an incomplete list of some of the most important ones:
ViewingMode - controls the initial viewing mode. The default is Page, but you can change that into Scroll
or TwoPage , if you want another default view. This can still be changed by the user, unless specifically
disabled.
IsFindEnabled - gives you the ability to disable searching in the document. If disabled, the search button
will be removed from the toolbar.
Zoom - allows you to set the default zoom level. The standard is 100%, but you can change this by using
the Zoom property.
1.12.4.1. Summary
We've now been through all the choices for a read-only FlowDocument wrapper, and as you can probably
see, which one to choose really depends on the task at hand.
If you just want simple FlowDocument rendering with a scrollbar you should go with the
FlowDocumentScrollViewer - it's simple and is the least space and resource consuming of the three. If you
want a paged view, go with the FlowDocumentPageViewer, unless you want your user to be able to switch
between the modes and be able to quickly search, in which case you should use the
FlowDocumentReader.
As a bare minimum example, here's our "Hello, world!" example from one of the first articles, created from
Code-behind instead of XAML:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.CodeBehindFlowDocumentSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="CodeBehindFlowDocumentSample" Height="200" Width="300">
<Grid>
<FlowDocumentScrollViewer Name="fdViewer" />
</Grid>
</Window>
using System;
using System.Windows;
using System.Windows.Documents;
using System.Windows.Media;
namespace WpfTutorialSamples.Rich_text_controls
{
public partial class CodeBehindFlowDocumentSample : Window
{
public CodeBehindFlowDocumentSample()
{
InitializeComponent();
fdViewer.Document = doc;
}
}
}
When compared to the small amount of XAML required to achieve the exact same thing, this is hardly
impressive:
<FlowDocument>
<Paragraph FontSize="36">Hello, world!</Paragraph>
<Paragraph FontStyle="Italic" TextAlignment="Left" FontSize="14"
Foreground="Gray">The ultimate programming greeting!</Paragraph>
</FlowDocument>
That's beside the point here though - sometimes it just makes more sense to handle stuff from Code-
behind, and as you can see, it's definitely possible.
The XAML code for the next example might look a bit overwhelming, but notice how simple it actually is -
just like HTML, you can format text simply by placing them in styled paragraphs. Now have a look at the
XAML. A screenshot of the result will follow directly after it:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.ExtendedFlowDocumentSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ExtendedFlowDocumentSample" Height="550" Width="500">
<Grid>
<FlowDocumentScrollViewer>
<FlowDocument>
<Paragraph>
<Image Source="http://www.wpf-
tutorial.com/images/logo.png" Width="90" Height="90" Margin="0,0,30,0"
/>
<Run FontSize="120">WPF</Run>
</Paragraph>
<Paragraph>
WPF, which stands for
<Bold>Windows Presentation Foundation</Bold>,
is Microsoft's latest approach to a GUI
framework, used with the .NET framework.
Some advantages include:
</Paragraph>
<List>
<ListItem>
<Paragraph>
It's newer and thereby more in tune
with current standards
</Paragraph>
</ListItem>
<Table CellSpacing="0">
<TableRowGroup>
<TableRow Background="Gainsboro"
FontWeight="Bold">
<TableCell></TableCell>
<TableCell>
<Paragraph TextAlignment="Right"
>WinForms</Paragraph>
</TableCell>
<TableCell>
<Paragraph TextAlignment="Right"
>WPF</Paragraph>
</TableCell>
</TableRow>
</TableRowGroup>
<TableRowGroup>
<TableRow>
<TableCell Background="Gainsboro"
FontWeight="Bold">
<Paragraph>Lines of code</
Paragraph>
</TableCell>
<TableCell>
<Paragraph TextAlignment="Right"
>1.718.000</Paragraph>
</TableCell>
I'm not going to go too much into details about each of the tags - hopefully they should make sense as
they are.
As you can see, including lists, images and tables are pretty easy, but in fact, you can include any WPF
control inside of your FlowDocument. Using the BlockUIContainer element you get access to all controls
that would otherwise only be available inside of a window. Here's an example:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.BlockUIContainerSample"
xmlns
Now we have a FlowDocument with a ListView inside of it, and as you can see from the screenshot, the
ListView works just like it normally would, including selections etc. Pretty cool!
1.12.6.1. Summary
By using the techniques described in the two examples of this article, pretty much anything is possible,
when creating FlowDocument documents. It's excellent for presenting visual information to the end-user, as
seen in many of the expensive reporting suites.
You can add a RichTextBox directly to the window, without any content - in that case, it will automatically
create a FlowDocument instance that you will be editing. Alternatively, you can wrap a FlowDocument
instance with the RichTextBox and thereby control the initial content. It could look like this:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.RichTextBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="RichTextBoxSample" Height="200" Width="300">
<Grid>
<RichTextBox Margin="10">
<FlowDocument>
<Paragraph FontSize="36">Hello, world!</Paragraph>
<Paragraph FontStyle="Italic" TextAlignment="Left"
FontSize="14" Foreground="Gray">Thanks to the RichTextBox control, this
FlowDocument is completely editable!</Paragraph>
</FlowDocument>
</RichTextBox>
With this example, you can start editing your rich text content straight away. However, now that the content
is no longer read-only, it's obviously interesting how you can manipulate the text, as well as work with the
selection. We'll look into that right now.
Another interesting aspect is of course working with the various formatting possibilities - we'll look into that
in the next article, where we actually implement a small, but fully functional rich text editor.
The next example will provide show off a range of functionality that works with the text and/or selection in
the RichTextBox control:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.RichTextBoxTextSelectionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="RichTextBoxTextSelectionSample" Height="300" Width
="400">
<DockPanel>
<WrapPanel DockPanel.Dock="Top">
<Button Name="btnGetText" Click="btnGetText_Click">Get
text</Button>
using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
namespace WpfTutorialSamples.Rich_text_controls
{
public partial class RichTextBoxTextSelectionSample : Window
{
public RichTextBoxTextSelectionSample()
{
InitializeComponent();
}
As you can see, the markup consists of a panel of buttons, a RichTextBox and a TextBox in the bottom, to
show the current selection status. Each of the four available buttons will work with the RichTextBox by
In Code-behind, we handle the four buttons click events, as well as the SelectionChanged event for the
RichTextBox, which allows us to show statistics about the current selection.
Pay special attention to the fact that instead of accessing a text property directly on the RichTextBox, as
we would do with a regular TextBox, we're using TextRange objects with TextPointer's from the
RichTextBox to obtain text from the control or the selection in the control. This is simply how it works with
RichTextBox, which, as already mentioned, doesnt work like a regular TextBox in several aspects.
Fortunately, it's very easy to fix. The extra spaces comes from the fact that paragraphs have a default
margin bigger than zero, so fixing it is as simple as changing this property, which we can do with a style,
like this:
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.RichTextBoxParagraphSpacingSampl
e"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="RichTextBoxParagraphSpacingSample" Height="150" Width
="300">
<Grid>
<RichTextBox Margin="10">
<RichTextBox.Resources>
<Style TargetType="{x:Type Paragraph}">
<Setter Property="Margin" Value="0" />
</Style>
</RichTextBox.Resources>
</RichTextBox>
</Grid>
</Window>
Now the lines don't have extra space around them, and if you want, you can place the style in the window
or even in App.xaml, if you want it to work for more than just a single RichTextBox.
1.12.7.3. Summary
The RichTextBox is easy to use, has lots of features straight out of the box, and can easily be used if you
In this article, we'll be using lots of controls and techniques that we've used in other parts of the tutorial, so
the explanations won't be too detailed. In case you need to freshen up on parts of it, you can always go
back for the fully detailed descriptions.
As a start, let's have a look at what we're going for. This should be the final result:
1.12.8.1. Interface
The interface consists of a ToolBar control with buttons and combo boxes on it. There are buttons for
loading and saving a document, buttons for controlling various font weight and style properties, and then
two combo boxes for controlling the font family and size.
Below the toolbar is the RichTextBox control, where all the editing will be done.
1.12.8.2. Commands
The first thing you might notice is the use of WPF Commands, which we've already discussed previously in
this article. We use the Open and Save commands from the ApplicationCommands class to load and save
the document, and we use the ToggleBold, ToggleItalic and ToggleUnderline commands from the
EditingCommands class for our style related buttons.
The advantage of using Commands is once again obvious, since the RichTextBox control already
We also get keyboard shortcuts for free - press Ctrl+B to activate ToggleBold, Ctrl+I to activate ToggleItalic
and Ctrl+U to activate ToggleUnderline.
Notice that I'm using a ToggleButton instead of a regular Button control. I want the button to be
checkable, if the selection is currently bold, and that's supported through the IsChecked property of the
ToggleButton. Unfortunately, WPF has no way of handling this part for us, so we need a bit of code to
update the various button and combo box states. More about that later.
The Open and Save commands can't be handled automatically, so we'll have to do that as usual, with a
CommandBinding for the Window and then an event handler in Code-behind:
<Window.CommandBindings>
<CommandBinding Command="ApplicationCommands.Open" Executed
="Open_Executed" />
<CommandBinding Command="ApplicationCommands.Save" Executed
="Save_Executed" />
</Window.CommandBindings>
public RichTextEditorSample()
{
InitializeComponent();
cmbFontFamily.ItemsSource = Fonts.SystemFontFamilies.OrderBy(f =>
f.Source);
cmbFontSize.ItemsSource = new List<double>() { 8, 9, 10, 11, 12,
14, 16, 18, 20, 22, 24, 26, 28, 36, 48, 72 };
}
Once again, wPF makes it easy for us to get a list of possible font families, by using the
This also means that we'll be handling changes differently. For the font family ComboBox, we can just
handle the SelectionChanged event, while we hook into the TextBoxBase.TextChanged event of the size
ComboBox, to handle the fact that the user can both select and manually enter a size.
WPF handles the implementation of the Bold, Italic and Underline commands for us, but for font family and
size, we'll have to manually change these values. Fortunately, it's quite easy to do, using the
ApplyPropertyValue() method. The above mentioned event handlers look like this.
rtbEditor.Selection.ApplyPropertyValue(Inline.FontFamilyProperty,
cmbFontFamily.SelectedItem);
}
Nothing too fancy here - we simply pass on the selected/entered value to the ApplyPropertyValue()
method, along with the property that we wish to change.
We want to update the state as soon as the cursor moves and/or the selection changes, and for that, the
SelectionChanged event of the RichTextBox is perfect. Here's how we handle it:
temp =
rtbEditor.Selection.GetPropertyValue(Inline.FontFamilyProperty);
cmbFontFamily.SelectedItem = temp;
temp =
rtbEditor.Selection.GetPropertyValue(Inline.FontSizeProperty);
cmbFontSize.Text = temp.ToString();
}
Quite a bit of lines, but the actual job only requires a couple of lines - we just repeat them with a small
variation to update each of the three buttons, as well as the two combo boxes.
The principle is quite simple. For the buttons, we use the GetPropertyValue() method to get the current
value for a given text property, e.g. the FontWeight, and then we update the IsChecked property depending
on whether the returned value is the same as the one we're looking for or not.
For the combo boxes, we do the same thing, but instead of setting an IsChecked property, we set the
SelectedItem or Text properties directly with the returned values.
An OpenFileDialog or SaveFileDialog is used to specify the location and filename, and then the text is
either loaded or saved by using a TextRange object, which we obtain directly from the RichTextBox, in
combination with a FileStream, which provides the access to the physical file. The file is loaded and saved
in the RTF format, but you can specify one of the other format types if you want your editor to support other
formats, e.g. plain text.
<Window x:Class
="WpfTutorialSamples.Rich_text_controls.RichTextEditorSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
using System;
using System.Linq;
using System.Collections.Generic;
using System.IO;
using System.Windows;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using Microsoft.Win32;
using System.Windows.Controls;
namespace WpfTutorialSamples.Rich_text_controls
{
public partial class RichTextEditorSample : Window
{
public RichTextEditorSample()
{
InitializeComponent();
cmbFontFamily.ItemsSource =
Fonts.SystemFontFamilies.OrderBy(f => f.Source);
cmbFontSize.ItemsSource = new List<double>() { 8, 9, 10,
11, 12, 14, 16, 18, 20, 22, 24, 26, 28, 36, 48, 72 };
}
temp =
rtbEditor.Selection.GetPropertyValue(Inline.FontFamilyProperty);
cmbFontFamily.SelectedItem = temp;
temp =
rtbEditor.Selection.GetPropertyValue(Inline.FontSizeProperty);
cmbFontSize.Text = temp.ToString();
}
rtbEditor.Selection.ApplyPropertyValue(Inline.FontFamilyProperty,
cmbFontFamily.SelectedItem);
}
rtbEditor.Selection.ApplyPropertyValue(Inline.FontSizeProperty,
cmbFontSize.Text);
}
}
}
And here's another screenshot where we've selected some text. Notice how the toolbar controls reflects
the state of the current selection:
1.12.8.7. Summary
As you can see, implementing a rich text editor in WPF is very simple, especially because of the excellent
RichTextBox control. If you want, you can easily extend this example with stuff like text alignment, colors,
lists and even tables.
Please be aware that while the above example should work just fine, there's absolutely no exception
handling or checking at all, to keep the amount of code to a minimum. There are several places which
could easily throw an exception, like the font size combo box, where one could cause an exception by
entering a non-numeric value. You should of course check all of this and handle possible exceptions if you
wish to expand on this example for your work.
A simple example on using the Border as described above could look like this:
<Window x:Class="WpfTutorialSamples.Misc_controls.BorderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="BorderSample" Height="170" Width="200">
<Grid Margin="10">
<Border Background="GhostWhite" BorderBrush="Gainsboro"
BorderThickness="1">
<StackPanel Margin="10">
<Button>Button 1</Button>
<Button Margin="0,10">Button 2</Button>
<Button>Button 3</Button>
</StackPanel>
</Border>
</Grid>
</Window>
The Border is completely lookless until you define either a background or a border brush and thickness, so
that's what I've done here, using the Background, BorderBrush and BorderThickness properties.
<Window x:Class="WpfTutorialSamples.Misc_controls.BorderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="BorderSample" Height="175" Width="200">
<Grid Margin="10">
<Border Background="GhostWhite" BorderBrush="Silver"
BorderThickness="1" CornerRadius="8,8,3,3">
<StackPanel Margin="10">
<Button>Button 1</Button>
<Button Margin="0,10">Button 2</Button>
<Button>Button 3</Button>
</StackPanel>
</Border>
</Grid>
</Window>
All I've done is adding the CornerRadius property. It can be specified with a single value, which will be
used for all four corners, or like I did in the example here, where I specify separate values for the top right
and left followed by the bottom right and left.
<Window x:Class="WpfTutorialSamples.Misc_controls.BorderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="BorderSample" Height="175" Width="200">
<Grid Margin="10">
<Border BorderBrush="Navy" BorderThickness="1,3,1,5">
<Border.Background>
In this case, I've specified a LinearGradientBrush to be used for the background of the Border and then a
more fitting border color. The LinearGradientBrush might not have the most obvious syntax, so I will explain
that in a later chapter, including other brush types, but for now, you can try my example and change the
values to see the result.
<Window x:Class="WpfTutorialSamples.Misc_controls.SliderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SliderSample" Height="100" Width="300">
<StackPanel VerticalAlignment="Center" Margin="10">
<Slider Maximum="100" />
</StackPanel>
</Window>
This will allow the end-user to select a value between 0 and 100 by dragging the button (referred to as the
thumb) along the line.
1.13.2.1. Ticks
In the example, I have dragged the thumb beyond the middle, but it's obviously hard to see the exact
value. One way to remedy this is to turn on ticks, which are small markers shown on the line to give a better
indication on how far the thumb is. Here's an example:
<Window x:Class="WpfTutorialSamples.Misc_controls.SliderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SliderSample" Height="100" Width="300">
<StackPanel VerticalAlignment="Center" Margin="10">
<Slider Maximum="100" TickPlacement="BottomRight"
TickFrequency="5" />
</StackPanel>
</Window>
Also notice my use of the TickFrequency property. It defaults to 1, but in an example where the range of
possible values goes from 0 to 100, this will result in 100 tick markers, which will have to be fitted into the
limited space. In a case like this, it makes sense to raise the TickFrequency to something that will make it
look less crowded.
<Window x:Class
="WpfTutorialSamples.Misc_controls.SliderSnapToTickSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SliderSnapToTickSample" Height="100" Width="300">
<StackPanel VerticalAlignment="Center" Margin="10">
<Slider Maximum="100" TickPlacement="BottomRight"
TickFrequency="10" IsSnapToTickEnabled="True" />
</StackPanel>
</Window>
Notice that I've changed the TickFrequency to 10, and then enabled the IsSnapToTickEnabled property.
A common scenario in using the Slider is to combine it with a TextBox, which will allow the user to see the
currently selected value, as well as changing it by entering a number instead of dragging the Slider thumb.
Normally, you would have to subscribe to change events on both the Slider and the TextBox and then
update accordingly, but a simple binding can do all of that for us:
<Window x:Class
="WpfTutorialSamples.Misc_controls.SliderBoundValueSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SliderBoundValueSample" Height="100" Width="300">
<DockPanel VerticalAlignment="Center" Margin="10">
<TextBox Text="{Binding ElementName=slValue, Path=Value,
UpdateSourceTrigger=PropertyChanged}" DockPanel.Dock="Right"
TextAlignment="Right" Width="40" />
<Slider Maximum="255" TickPlacement="BottomRight"
TickFrequency="5" IsSnapToTickEnabled="True" Name="slValue" />
</DockPanel>
</Window>
Now you can change the value by using either the Slider or by entering a value in the TextBox, and it will
be immediately reflected in the other control. As an added bonus, we get simple validation as well, without
any extra work, like if we try to enter a non-numeric value in the TextBox:
<Window x:Class
="WpfTutorialSamples.Misc_controls.SliderValueChangedSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SliderValueChangedSample" Height="200" Width="300">
<StackPanel Margin="10" VerticalAlignment="Center">
<DockPanel VerticalAlignment="Center" Margin="10">
<Label DockPanel.Dock="Left" FontWeight="Bold">R:</Label>
<TextBox Text="{Binding ElementName=slColorR, Path=Value,
UpdateSourceTrigger=PropertyChanged}" DockPanel.Dock="Right"
TextAlignment="Right" Width="40" />
<Slider Maximum="255" TickPlacement="BottomRight"
TickFrequency="5" IsSnapToTickEnabled="True" Name="slColorR"
ValueChanged="ColorSlider_ValueChanged" />
</DockPanel>
using System;
using System.Windows;
using System.Windows.Media;
namespace WpfTutorialSamples.Misc_controls
{
public partial class SliderValueChangedSample : Window
{
public SliderValueChangedSample()
{
InitializeComponent();
}
Each slider subscribes to the same ValueChanged event, in which we create a new Color instance, based
on the currently selected values and then uses this color to create a new SolidColorBrush for the
Background property of the Window.
All in all, this is a pretty good example of what the Slider control can be used for.
<Window x:Class="WpfTutorialSamples.Misc_controls.ProgressBarSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ProgressBarSample" Height="100" Width="300">
<Grid Margin="20">
<ProgressBar Minimum="0" Maximum="100" Value="75" />
</Grid>
</Window>
In this case, I've used a pretty standard approach of showing progress as a percentage (between 0 and
100%), giving it an initial value of 75. Another approach is to use actual minimum and maximum values
from a list of tasks you're performing. For instance, if you loop through a collected list of files while checking
each of them, you can set the Minimum property to 0, the Maximum to the amount of files in your list, and
then just increment as you loop through it.
The ProgressBar is, just like other standard WPF controls, rendered to match the visual style of the
operating system. Here on Windows 7, it has a nice animated gradient, as seen on the screenshot.
In most situations you will use the ProgressBar to show progress for some heavy/lengthy task, and this this
is where most new programmers run into a very common problem: If you do a piece of heavy work on the
UI thread, while trying to simultaneously update e.g. a ProgressBar control, you will soon realize that you
can't do both, at the same time, on the same thread. Or to be more clear, you can, but the ProgressBar
won't actually show each update to the progress before the task is completed, which pretty much renders it
useless.
<Window x:Class
="WpfTutorialSamples.Misc_controls.ProgressBarTaskOnUiThread"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ProgressBarTaskOnUiThread" Height="100" Width="300"
ContentRendered="Window_ContentRendered">
<Grid Margin="20">
<ProgressBar Minimum="0" Maximum="100" Name="pbStatus" />
</Grid>
</Window>
using System;
using System.Threading;
using System.Windows;
namespace WpfTutorialSamples.Misc_controls
{
public partial class ProgressBarTaskOnUiThread : Window
{
public ProgressBarTaskOnUiThread()
{
InitializeComponent();
}
A very basic example, where, as soon as the window is ready, we do a loop from 0 to 100 and in each
iteration, we increment the value of the ProgressBar. Any modern computer can do this faster than you can
Notice that the cursor indicates that something is happening, yet the ProgressBar still looks like it did at the
start (empty). As soon as the loop, which represents our lengthy task, is done, the ProgressBar will look like
this:
That really didn't help your users see the progress! Instead, we have to perform the task on a worker
thread and then push updates to the UI thread, which will then be able to immediately process and visually
show these updates. An excellent tool for handling this job is the BackgroundWorker class, which we talk
much more about elsewhere in this tutorial. Here's the same example as above, but this time using a
BackgroundWorker:
<Window x:Class
="WpfTutorialSamples.Misc_controls.ProgressBarTaskOnWorkerThread"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ProgressBarTaskOnWorkerThread" Height="100" Width="300"
ContentRendered="Window_ContentRendered">
<Grid Margin="20">
<ProgressBar Minimum="0" Maximum="100" Name="pbStatus" />
</Grid>
</Window>
using System;
using System.ComponentModel;
using System.Threading;
namespace WpfTutorialSamples.Misc_controls
{
public partial class ProgressBarTaskOnWorkerThread : Window
{
public ProgressBarTaskOnWorkerThread()
{
InitializeComponent();
}
worker.RunWorkerAsync();
}
As you can see on the screenshot, the progress is now updated all the way through the task, and as the
cursor indicates, no hard work is being performed on the UI thread, which means that you can still interact
Please be aware that while the BackgroundWorker does help a lot with multithreading related problems,
there are still some things you should be aware of, so please have a look at the BackgroundWorker articles
in this tutorial before doing anything more advanced than a scenario like the one above.
1.13.3.2. Indeterminate
For some tasks, expressing the progress as a percentage is not possible or you simply don't know how
long it will take. For those situations, the indeterminate progress bar has been invented, where an
animation lets the user know that something is happening, while indicating that the running time can't be
determined.
The WPF ProgressBar supports this mode through the use of the IsIndeterminate property, which we'll
show you in the next example:
<Window x:Class
="WpfTutorialSamples.Misc_controls.ProgressBarIndeterminateSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ProgressBarIndeterminateSample" Height="100" Width
="300">
<Grid Margin="20">
<ProgressBar Minimum="0" Maximum="100" Name="pbStatus"
IsIndeterminate="True" />
</Grid>
</Window>
<Window x:Class="WpfTutorialSamples.Misc_controls.ProgressBarTextSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ProgressBarTextSample" Height="100" Width="300">
<Grid Margin="20">
<ProgressBar Minimum="0" Maximum="100" Value="75" Name
="pbStatus" />
<TextBlock Text="{Binding ElementName=pbStatus, Path=Value,
StringFormat={}{0:0}%}" HorizontalAlignment="Center" VerticalAlignment
="Center" />
</Grid>
</Window>
We accomplish the above by putting the ProgressBar and the TextBlock showing the percentage inside of
the same Grid, without specifying any rows or columns. This will render the TextBlock on top of the
ProgressBar, which is exactly what we want here, because the TextBlock has a transparent background by
default.
We use a binding to make sure that the TextBlock show the same value as the ProgressBar. Notice the
special StringFormat syntax, which allows us to show the value with a percentage sign postfix - it might
look a bit strange, but please see the StringFormat article of this tutorial for more information on it.
I've done things a bit differently in this article: Instead of starting off with a very limited example and then
adding to it, I've create just one but more complex example. It illustrates how easy you can get a small web
browser up and running. It's very basic in its functionality, but you can easily extend it if you want to. Here's
how it looks:
<Window x:Class
="WpfTutorialSamples.Misc_controls.WebBrowserControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
using System;
using System.Windows;
using System.Windows.Input;
}
}
The code might seem a bit overwhelming at first, but if you take a second look, you'll realize that there's a
lot of repetition in it.
Let's start off by talking about the XAML part. Notice that I'm using several concepts discussed elsewhere
in this tutorial, including the ToolBar control and WPF commands. The ToolBar is used to host a couple of
buttons for going backward and forward. After that, we have an address bar for entering and showing the
current URL, along with a button for navigating to the entered URL.
Below the toolbar, we have the actual WebBrowser control. As you can see, using it only requires a single
line of XAML - in this case we subscribe to the Navigating event, which occurs as soon as the
WebBrowser starts navigating to a URL.
In Code-behind, we start off by navigating to a URL already in the constructor of the Window, to have
something to show immediately instead of a blank control. We then have the txtUrl_KeyUp event, in which
we check to see if the user has hit Enter inside of the address bar - if so, we start navigating to the entered
URL.
The wbSample_Navigating event makes sure that the address bar is updated each time a new navigation
starts. This is important because we want it to show the current URL no matter if the user initiated the
navigation by entering a new URL or by clicking a link on the webpage.
For the last command, we allow it to always execute and when it does, we use the Navigate() method once
again.
1.13.4.1. Summary
As you can see, hosting and using a complete webbrowser inside of your application becomes very easy
with the WebBrowser control. However, you should be aware that the WPF version of WebBrowser is a bit
limited when compared to the WinForms version, but for basic usage and navigation, it works fine.
If you wish to use the WinForms version instead, you may do so using the WindowsFormsHost, which is
explained elsewhere in this tutorial.
To use the WindowsFormsHost and controls from WinForms, you need to add a reference to the following
assemblies in your application:
• WindowsFormsIntegration
• System.Windows.Forms
In Visual Studio, this is done by right-clicking the "References" node in your project and selecting "Add
reference":
In the dialog that pops up, you should select "Assemblies" and then check the two assemblies that we
need to add:
A small example is the DocumentTitle property and corresponding DocumentTitleChanged event, which
<Window x:Class
="WpfTutorialSamples.Misc_controls.WindowsFormsHostSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:wf="clr-
namespace:System.Windows.Forms;assembly=System.Windows.Forms"
Title="WindowsFormsHostSample" Height="350" Width="450">
<Grid>
<WindowsFormsHost Name="wfhSample">
<WindowsFormsHost.Child>
<wf:WebBrowser DocumentTitleChanged
="wbWinForms_DocumentTitleChanged" />
</WindowsFormsHost.Child>
</WindowsFormsHost>
</Grid>
using System;
using System.Windows;
namespace WpfTutorialSamples.Misc_controls
{
public partial class WindowsFormsHostSample : Window
{
public WindowsFormsHostSample()
{
InitializeComponent();
(wfhSample.Child as
System.Windows.Forms.WebBrowser).Navigate("http://www.wpf-tutorial.com"
);
}
Pay special attention to the line where we add the WinForms namespace to the window, so that we may
reference controls from it:
xmlns:wf="clr-
namespace:System.Windows.Forms;assembly=System.Windows.Forms"
This will allow us to reference WinForms controls using the wf: prefix.
The WindowsFormsHost is fairly simple to use, as you can see. It has a Child property, in which you can
define a single WinForms control, much like the WPF Window only holds a single root control. If you need
more controls from WinForms inside of your WindowsFormsHost, you can use the Panel control from
WinForms or any of the other container controls.
The WinForms WebBrowser control is used by referencing the System.Windows.Forms assembly, using
the wf prefix, as explained above.
Congratulations, you now have a WPF application with a WinForms WebBrowser hosted inside of it.
1.13.5.2. Summary
As you can see, using WinForms controls inside of your WPF applications is pretty easy, but the question
remains: Is it a good idea?
In general, you may want to avoid it. There are a number of issues that may or may not affect your
application (a lot of them are described in this MSDN article: http://msdn.microsoft.com/en-
us/library/aa970911%28v=VS.100%29.aspx), but a more serious problem is that this kind of UI framework
mixing might not be supported in future versions of the .NET framework.
In the end though, the decision is up to you - do you really need the WinForms control or is there a WPF
alternative that might work just as well?
Just like with most other WPF controls, the TabControl is very easy to get started with. Here's a very basic
example:
<Window x:Class="WpfTutorialSamples.Misc_controls.TabControlSample"
<Window x:Class="WpfTutorialSamples.Misc_controls.TabControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TabControlSample" Height="200" Width="250">
<Grid>
<TabControl>
<TabItem Header="General">
<Label Content="Content goes here..." />
</TabItem>
<TabItem Header="Security" />
<TabItem Header="Details" />
</TabControl>
</Grid>
</Window>
<Window x:Class
="WpfTutorialSamples.Misc_controls.TabControlWithCustomHeadersSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TabControlWithCustomHeadersSample" Height="200" Width
="250">
<Grid>
<Grid>
<TabControl>
<TabItem>
<TabItem.Header>
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_blue.png" />
<TextBlock Text="Blue" Foreground
="Blue" />
</StackPanel>
</TabItem.Header>
<Label Content="Content goes here..." />
</TabItem>
<TabItem>
<TabItem.Header>
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_red.png" />
<TextBlock Text="Red" Foreground
="Red" />
</StackPanel>
The amount of markup might be a bit overwhelming, but as you can probably see once you dig into it, it's
all very simple. Each of the tabs now has a TabControl.Header element, which contains a StackPanel,
which in turn contains an Image and a TextBlock control. This allows us to have an image on each of the
tabs as well as customize the color of the text (we could have made it bold, italic or another size as well).
<Window x:Class
</DockPanel>
</Window>
using System;
using System.Windows;
using System.Windows.Controls;
namespace WpfTutorialSamples.Misc_controls
{
public partial class ControllingTheTabControlSample : Window
{
public ControllingTheTabControlSample()
{
InitializeComponent();
}
The first two buttons uses the SelectedIndex property to determine where we are and then either
subtracts or adds one to that value, making sure that the new index doesn't fall below or above the amount
of available items. The third button uses the SelectedItem property to get a reference to the selected tab.
As you can see, I have to typecast it into the TabItem class to get a hold of the header property, since the
SelectedProperty is of the object type by default.
1.14.1.3. Summary
The TabControl is great when you need a clear separation in a dialog or when there's simply not enough
space for all the controls you want in it. In the next couple of chapters, we'll look into some of the
possibilites there are when using the TabControl for various purposes.
However, using the TabStripPlacement property, we can very easily change this:
<Window x:Class
="WpfTutorialSamples.Misc_controls.TabStripPlacementSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TabStripPlacementSample" Height="200" Width="250">
<Grid>
<TabControl TabStripPlacement="Bottom">
<TabItem Header="General">
<Label Content="Content goes here..." />
</TabItem>
<TabItem Header="Security" />
<TabItem Header="Details" />
</TabControl>
</Grid>
</Window>
The TabStripPlacement can be set to Top, Bottom, Left and Right. However, if we set it to Left or Right, we
get a result like this:
<Window x:Class
="WpfTutorialSamples.Misc_controls.TabStripPlacementSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TabStripPlacementSample" Height="200" Width="250"
UseLayoutRounding="True">
<Grid>
<TabControl TabStripPlacement="Left">
<TabControl.Resources>
<Style TargetType="{x:Type TabItem}">
<Setter Property="HeaderTemplate">
<Setter.Value>
If you haven't yet read the chapters on templates or styles, this might seem a bit confusing, but what we do
is using a style targeted at the TabItem elements, where we override the HeaderTemplate and then apply a
rotate transform to the tabs. For tabs placed on the left side, we rotate 270 degrees - if placed on the right,
you should only rotate 90 degrees, to make it look correct.
So, if you would like to get full control of how the tabs of your TabControl looks, check out the next
example:
<Window x:Class="WpfTutorialSamples.Misc_controls.StyledTabItemsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyledTabItemsSample" Height="150" Width="250">
<Grid>
<TabControl Margin="10" BorderThickness="0" Background
="LightGray">
<TabControl.Resources>
<Style TargetType="TabItem">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="TabItem"
>
<Grid Name="Panel">
<ContentPresenter x:Name
="ContentSite"
VerticalAlignment
="Center"
HorizontalAlignment
="Center"
ContentSource="Header"
Margin="10,2"/>
</Grid>
<ControlTemplate.Triggers>
<Trigger Property
="IsSelected" Value="True">
<Setter TargetName
="Panel" Property="Background" Value="LightSkyBlue" />
</Trigger>
<Trigger Property
As you can see, this makes the TabControl looks a bit Windows 8'ish, with no borders and a less subtle
color to mark the selected tab and no background for the unselected tabs. All of this is accomplished by
changing the ControlTemplate, using a Style. By adding a ContentPresenter control, we specify where the
content of the TabItem should be placed. We also have a couple of triggers, which controls the background
color of the tabs based on the IsSelected property.
In case you want a less subtle look, it's as easy as changing the template. For instance, you might want a
border, but with round corners and a gradient background - no problem! Check out this next example,
where we accomplish just that:
<Window x:Class
="WpfTutorialSamples.Misc_controls.StyledTabItemsWithBorderSample"
xmlns
As you can see, I pretty much just added a Border control around the ContentPresenter to achieve this
changed look. Hopefully this should demonstrate just how easy it is to get custom styled tabs and how
many possibilities there are in this technique.
<Window x:Class="WpfTutorialSamples.ItemsControl.ItemsControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="ItemsControlSample" Height="150" Width="200">
<Grid Margin="10">
<ItemsControl>
<system:String>ItemsControl Item #1</system:String>
<system:String>ItemsControl Item #2</system:String>
<system:String>ItemsControl Item #3</system:String>
<system:String>ItemsControl Item #4</system:String>
<system:String>ItemsControl Item #5</system:String>
</ItemsControl>
</Grid>
</Window>
To demonstrate that, I've whipped up an example where we display a TODO list to the user, and to show
you just how flexible everything gets once you define your own templates, I've used a ProgressBar control
to show you the current completion percentage. First some code, then a screenshot and then an
explanation of it all:
<Window x:Class
="WpfTutorialSamples.ItemsControl.ItemsControlDataBindingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ItemsControlDataBindingSample" Height="150" Width="300"
>
<Grid Margin="10">
<ItemsControl Name="icTodoList">
<ItemsControl.ItemTemplate>
<DataTemplate>
<Grid Margin="0,0,0,5">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="*" />
<ColumnDefinition Width="100" />
</Grid.ColumnDefinitions>
<TextBlock Text="{Binding Title}" />
<ProgressBar Grid.Column="1" Minimum="0"
Maximum="100" Value="{Binding Completion}" />
</Grid>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</Grid>
</Window>
namespace WpfTutorialSamples.ItemsControl
{
public partial class ItemsControlDataBindingSample : Window
{
public ItemsControlDataBindingSample()
{
InitializeComponent();
icTodoList.ItemsSource = items;
}
}
The most important part of this example is the template that we specify inside of the ItemsControl, using a
The template now represents a TodoItem, which we declare in the Code-behind file, where we also
instantiate a number of them and add them to a list. In the end, this list is assigned to the ItemsSource
property of our ItemsControl, which then does the rest of the job for us. Each item in the list is displayed by
using our template, as you can see from the resulting screenshot.
<Window x:Class
="WpfTutorialSamples.ItemsControl.ItemsControlPanelSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="ItemsControlPanelSample" Height="150" Width="250">
<Grid Margin="10">
<ItemsControl>
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
<WrapPanel />
</ItemsPanelTemplate>
</ItemsControl.ItemsPanel>
<ItemsControl.ItemTemplate>
<DataTemplate>
<Button Content="{Binding}" Margin="0,0,5,5" />
</DataTemplate>
</ItemsControl.ItemTemplate>
<system:String>Item #1</system:String>
<system:String>Item #2</system:String>
<system:String>Item #3</system:String>
<system:String>Item #4</system:String>
<system:String>Item #5</system:String>
</ItemsControl>
</Grid>
We specify that the ItemsControl should use a WrapPanel as its template by declaring one in the
ItemsPanelTemplate property and just for fun, we throw in an ItemTemplate that causes the strings to be
rendered as buttons. You can use any of the WPF panels, but some are more useful than others.
Another good example is the UniformGrid panel, where we can define a number of columns and then have
our items neatly shown in equally-wide columns:
<Window x:Class
="WpfTutorialSamples.ItemsControl.ItemsControlPanelSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="ItemsControlPanelSample" Height="150" Width="250">
<Grid Margin="10">
<ItemsControl>
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
<UniformGrid Columns="2" />
</ItemsPanelTemplate>
</ItemsControl.ItemsPanel>
<ItemsControl.ItemTemplate>
<DataTemplate>
<Button Content="{Binding}" Margin="0,0,5,5" />
</DataTemplate>
</ItemsControl.ItemTemplate>
<system:String>Item #1</system:String>
<system:String>Item #2</system:String>
<system:String>Item #3</system:String>
<system:String>Item #4</system:String>
WPF makes this very easy to solve though. There are a number of possible solutions, for instance you can
alter the template used by the ItemsControl to include a ScrollViewer control, but the easiest solution is to
simply throw a ScrollViewer around the ItemsControl. Here's an example:
<Window x:Class="WpfTutorialSamples.ItemsControl.ItemsControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:system="clr-namespace:System;assembly=mscorlib"
Title="ItemsControlSample" Height="150" Width="200">
<Grid Margin="10">
<ScrollViewer VerticalScrollBarVisibility="Auto"
HorizontalScrollBarVisibility="Auto">
I set the two visibility options to Auto, to make them only visible when needed. As you can see from the
screenshot, you can now scroll through the list of items.
1.15.1.5. Summary
The ItemsControl is great when you want full control of how your data is displayed, and when you don't
need any of your content to be selectable. If you want the user to be able to select items from the list, then
you're better off with one of the other controls, e.g. the ListBox or the ListView. They will be described in
upcoming chapters.
<Window x:Class="WpfTutorialSamples.ListBox_control.ListBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListBoxSample" Height="120" Width="200">
<Grid Margin="10">
<ListBox>
<ListBoxItem>ListBox Item #1</ListBoxItem>
<ListBoxItem>ListBox Item #2</ListBoxItem>
<ListBoxItem>ListBox Item #3</ListBoxItem>
</ListBox>
</Grid>
</Window>
This is as simple as it gets: We declare a ListBox control, and inside of it, we declare three ListBoxItem's,
each with its own text. However, since the ListBoxItem is actually a ContentControl, we can define custom
content for it:
<Window x:Class="WpfTutorialSamples.ListBox_control.ListBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListBoxSample" Height="120" Width="200">
<Grid Margin="10">
<ListBox>
For each of the ListBoxItem's we now add a StackPanel, in which we add an Image and a TextBlock. This
gives us full control of the content as well as the text rendering, as you can see from the screenshot, where
different colors have been used for each of the numbers.
From the screenshot you might also notice another difference when comparing the ItemsControl to the
ListBox: By default, a border is shown around the control, making it look like an actual control instead of
just output.
I have re-used the TODO based example from the ItemsControl article, where we build a cool TODO list
using a simple Code-behind class and, in this case, a ListBox control for the visual representation. Here's
the example:
<Window x:Class
="WpfTutorialSamples.ListBox_control.ListBoxDataBindingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListBoxDataBindingSample" Height="150" Width="300">
<Grid Margin="10">
<ListBox Name="lbTodoList" HorizontalContentAlignment
="Stretch">
<ListBox.ItemTemplate>
<DataTemplate>
<Grid Margin="0,2">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="*" />
<ColumnDefinition Width="100" />
</Grid.ColumnDefinitions>
<TextBlock Text="{Binding Title}" />
<ProgressBar Grid.Column="1" Minimum="0"
Maximum="100" Value="{Binding Completion}" />
</Grid>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
</Grid>
</Window>
using System;
using System.Windows;
using System.Collections.Generic;
namespace WpfTutorialSamples.ListBox_control
{
lbTodoList.ItemsSource = items;
}
}
All the magic happens in the ItemTemplate that we have defined for the ListBox. In there, we specify that
each ListBox item should consist of a Grid, divided into two columns, with a TextBlock showing the title in
the first and a ProgressBar showing the completion status in the second column. To get the values out, we
use some very simple data binding, which is all explained in the data binding part of this tutorial.
In the Code-behind file, we have declared a very simple TodoItem class to hold each of our TODO items.
In the constructor of the window, we initialize a list, add three TODO items to it and then assign it to the
ItemsSource of the ListBox. The combination of the ItemsSource and the ItemTemplate we specified in the
XAML part, this is all WPF need to render all of the items as a TODO list.
By using the Stretch alignment, each item is stretched to take up the full amount of available space, as you
can see from the previous screenshot.
<Window x:Class
="WpfTutorialSamples.ListBox_control.ListBoxSelectionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListBoxSelectionSample" Height="250" Width="450">
<DockPanel Margin="10">
<StackPanel DockPanel.Dock="Right" Margin="10,0">
<StackPanel.Resources>
<Style TargetType="Button">
<Setter Property="Margin" Value="0,0,0,5" />
</Style>
</StackPanel.Resources>
<TextBlock FontWeight="Bold" Margin="0,0,0,10">ListBox
selection</TextBlock>
<Button Name="btnShowSelectedItem" Click
="btnShowSelectedItem_Click">Show selected</Button>
using System;
using System.Windows;
using System.Collections.Generic;
namespace WpfTutorialSamples.ListBox_control
{
public partial class ListBoxSelectionSample : Window
{
public ListBoxSelectionSample()
{
InitializeComponent();
List<TodoItem> items = new List<TodoItem>();
lbTodoList.ItemsSource = items;
}
For each of the buttons, I have defined a click handler in the Code-behind. Each action should be pretty
self-explanatory and the C# code used is fairly simple, but if you're still in doubt, try running the example on
your own machine and test out the various possibilities in the example.
1.15.2.3. Summary
The ListBox control is much like the ItemsControl and several of the same techniques can be used. The
ListBox does offer a bit more functionality when compared to the ItemsControl, especially the selection
handling. For even more functionality, like column headers, you should have a look at the ListView control,
which is given a very thorough description later on in this tutorial with several articles explaining all the
functionality.
<Window x:Class="WpfTutorialSamples.ComboBox_control.ComboBoxSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ComboBoxSample" Height="150" Width="200">
<StackPanel Margin="10">
<ComboBox>
<ComboBoxItem>ComboBox Item #1</ComboBoxItem>
<ComboBoxItem IsSelected="True">ComboBox Item #2</
ComboBoxItem>
<ComboBoxItem>ComboBox Item #3</ComboBoxItem>
</ComboBox>
</StackPanel>
</Window>
In the screenshot, I have activated the control by clicking it, causing the list of items to be displayed. As
you can see from the code, the ComboBox, in its simple form, is very easy to use. All I've done here is
manually add some items, making one of them the default selected item by setting the IsSelected property
on it.
<Window x:Class
="WpfTutorialSamples.ComboBox_control.ComboBoxCustomContentSample"
For each of the ComboBoxItem's we now add a StackPanel, in which we add an Image and a TextBlock.
<Window x:Class
="WpfTutorialSamples.ComboBox_control.ComboBoxDataBindingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ComboBoxDataBindingSample" Height="200" Width="200">
<StackPanel Margin="10">
<ComboBox Name="cmbColors">
<ComboBox.ItemTemplate>
<DataTemplate>
<StackPanel Orientation="Horizontal">
<Rectangle Fill="{Binding Name}" Width
="16" Height="16" Margin="0,2,5,2" />
<TextBlock Text="{Binding Name}" />
</StackPanel>
</DataTemplate>
</ComboBox.ItemTemplate>
</ComboBox>
</StackPanel>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Media;
namespace WpfTutorialSamples.ComboBox_control
{
public partial class ComboBoxDataBindingSample : Window
{
public ComboBoxDataBindingSample()
{
It's actually quite simple: In the Code-behind, I obtain a list of all the colors using a Reflection based
approach with the Colors class. I assign it to the ItemsSource property of the ComboBox, which then
renders each color using the template I have defined in the XAML part.
Each item, as defined by the ItemTemplate, consists of a StackPanel with a Rectangle and a TextBlock,
each bound to the color value. This gives us a complete list of colors, with minimal effort - and it looks
pretty good too, right?
1.15.3.3. IsEditable
In the first examples, the user was only able to select from our list of items, but one of the cool things about
the ComboBox is that it supports the possibility of letting the user both select from a list of items or enter
their own value. This is extremely useful in situations where you want to help the user by giving them a pre-
defined set of options, while still giving them the option to manually enter the desired value. This is all
controlled by the IsEditable property, which changes the behavior and look of the ComboBox quite a bit:
<Window x:Class
="WpfTutorialSamples.ComboBox_control.ComboBoxEditableSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ComboBoxEditableSample" Height="150" Width="200">
<StackPanel Margin="10">
<ComboBox IsEditable="True">
As you can see, I can enter a completely different value or pick one from the list. If picked from the list, it
simply overwrites the text of the ComboBox.
As a lovely little bonus, the ComboBox will automatically try to help the user select an existing value when
the user starts typing, as you can see from the next screenshot, where I just started typing "Co":
By default, the matching is not case-sensitive but you can make it so by setting the
IsTextSearchCaseSensitive to True. If you don't want this auto complete behavior at all, you can disable it
by setting the IsTextSearchEnabled to False.
<Window x:Class
="WpfTutorialSamples.ComboBox_control.ComboBoxSelectionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ComboBoxSelectionSample" Height="125" Width="250">
<StackPanel Margin="10">
<ComboBox Name="cmbColors" SelectionChanged
="cmbColors_SelectionChanged">
<ComboBox.ItemTemplate>
<DataTemplate>
<StackPanel Orientation="Horizontal">
<Rectangle Fill="{Binding Name}" Width
="16" Height="16" Margin="0,2,5,2" />
<TextBlock Text="{Binding Name}" />
</StackPanel>
</DataTemplate>
</ComboBox.ItemTemplate>
</ComboBox>
<WrapPanel Margin="15" HorizontalAlignment="Center">
<Button Name="btnPrevious" Click="btnPrevious_Click"
Width="55">Previous</Button>
<Button Name="btnNext" Click="btnNext_Click" Margin="5,0"
Width="55">Next</Button>
<Button Name="btnBlue" Click="btnBlue_Click" Width="55">
Blue</Button>
</WrapPanel>
</StackPanel>
</Window>
using System;
using System.Collections.Generic;
using System.Reflection;
using System.Windows;
using System.Windows.Media;
namespace WpfTutorialSamples.ComboBox_control
{
The interesting part of this example is the three event handlers for our three buttons, as well as the
SelectionChanged event handler. In the first two, we select the previous or the next item by reading the
In the third event handler, we use the SelectedItem to select a specific item based on the value. I do a bit
of extra work here (using .NET reflection), because the ComboBox is bound to a list of properties, each
being a color, instead of a simple list of colors, but basically it's all about giving the value contained by one
of the items to the SelectedItem property.
In the fourth and last event handler, I respond to the selected item being changed. When that happens, I
read the selected color (once again using Reflection, as described above) and then use the selected color
to create a new background brush for the Window. The effect can be seen on the screenshot.
If you're working with an editable ComboBox (IsEditable property set to true), you can read the Text
property to know the value the user has entered or selected.
The WPF ListView does use a ListViewItem class for its most basic items, but if you compare it to the
WinForms version, you might start looking for properties like ImageIndex, Group and SubItems, but they're
not there. The WPF ListView handles stuff like item images, groups and their sub items in a completely
different way.
1.16.1.2. Summary
The ListView is a complex control, with lots of possibilities and especially in the WPF version, you get to
customize it almost endlessly if you want to. For that reason, we have dedicated an entire category to all
the ListView articles here on the site. Click on to the next article to get started.
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewBasicSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewBasicSample" Height="200" Width="200">
<Grid>
<ListView Margin="10">
<ListViewItem>A ListView</ListViewItem>
<ListViewItem IsSelected="True">with several</
ListViewItem>
<ListViewItem>items</ListViewItem>
</ListView>
</Grid>
</Window>
This is pretty much as simple as it gets, using manually specified ListViewItem to fill the list and with
nothing but a text label representing each item - a bare minimum WPF ListView control.
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewBasicSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewBasicSample" Height="200" Width="200">
<Grid>
<ListView Margin="10">
<ListViewItem>
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_green.png" Margin
="0,0,5,0" />
<TextBlock>Green</TextBlock>
</StackPanel>
</ListViewItem>
<ListViewItem>
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_blue.png" Margin="0,0,5,0"
/>
<TextBlock>Blue</TextBlock>
</StackPanel>
</ListViewItem>
<ListViewItem IsSelected="True">
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_red.png" Margin="0,0,5,0"
/>
<TextBlock>Red</TextBlock>
</StackPanel>
</ListViewItem>
</ListView>
</Grid>
</Window>
What we do here is very simple. Because the ListViewItem derives from the ContentControl class, we can
specify a WPF control as its content. In this case, we use a StackPanel, which has an Image and a
TextBlock as its child controls.
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewDataBindingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewDataBindingSample" Height="300" Width="300">
<Grid>
<ListView Margin="10" Name="lvDataBinding"></ListView>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.ListView_control
{
public partial class ListViewDataBindingSample : Window
{
public ListViewDataBindingSample()
{
InitializeComponent();
List<User> items = new List<User>();
items.Add(new User() { Name = "John Doe", Age = 42 });
items.Add(new User() { Name = "Jane Doe", Age = 39 });
items.Add(new User() { Name = "Sammy Doe", Age = 13 });
lvDataBinding.ItemsSource = items;
}
}
We populate a list of our own User objects, each user having a name and an age. The data binding
process happens automatically as soon as we assign the list to the ItemsSource property of the ListView,
but the result is a bit discouraging:
Each user is represented by their type name in the ListView. This is to be expected, because .NET doesn't
have a clue about how you want your data to be displayed, so it just calls the ToString() method on each
object and uses that to represent the item. We can use that to our advantage and override the ToString()
method, to get a more meaningful output. Try replacing the User class with this version:
This is a much more user friendly display and will do just fine in some cases, but relying on a simple string
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewItemTemplateSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewItemTemplateSample" Height="150" Width="350">
<Grid>
<ListView Margin="10" Name="lvDataBinding">
<ListView.ItemTemplate>
<DataTemplate>
<WrapPanel>
<TextBlock Text="Name: " />
<TextBlock Text="{Binding Name}"
FontWeight="Bold" />
<TextBlock Text=", " />
<TextBlock Text="Age: " />
<TextBlock Text="{Binding Age}" FontWeight
="Bold" />
<TextBlock Text=" (" />
<TextBlock Text="{Binding Mail}"
TextDecorations="Underline" Foreground="Blue" Cursor="Hand" />
<TextBlock Text=")" />
</WrapPanel>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
We use a bunch of TextBlock controls to build each item, where we put part of the text in bold. For the e-
mail address, which we added to this example, we underline it, give it a blue color and change the mouse
cursor, to make it behave like a hyperlink.
1.16.3.2. Summary
By using the GridView, you can get several columns of data in your ListView, much like you see it in
Windows Explorer. Just to make sure that everyone can visualize it, we'll start off with a basic example:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewGridViewSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewGridViewSample" Height="200" Width="400">
<Grid>
<ListView Margin="10" Name="lvUsers">
<ListView.View>
<GridView>
<GridViewColumn Header="Name" Width="120"
DisplayMemberBinding="{Binding Name}" />
<GridViewColumn Header="Age" Width="50"
DisplayMemberBinding="{Binding Age}" />
<GridViewColumn Header="Mail" Width="150"
DisplayMemberBinding="{Binding Mail}" />
</GridView>
</ListView.View>
</ListView>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.ListView_control
{
public partial class ListViewGridViewSample : Window
{
public ListViewGridViewSample()
{
So, we use the same User class as previously, for test data, which we then bind to the ListView. This is all
the same as we saw in previous chapters, but as you can see from the screenshot, the layout is very
different. This is the power of data binding - the same data, but presented in a completely different way, just
by changing the markup.
In the markup (XAML), we define a View for the ListView, using the ListView.View property. We set it to a
GridView, which is currently the only included view type in WPF (you can easily create your own though!).
The GridView is what gives us the column-based view that you see on the screenshot.
The GridViewColumn will use the DisplayMemberBinding as its first priority, it it's present. The second
choice will be the CellTemplate property, which we'll use for this example:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewGridViewCellTemplateSample
"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewGridViewCellTemplateSample" Height="200" Width
="400">
<Grid>
<ListView Margin="10" Name="lvUsers">
<ListView.View>
<GridView>
<GridViewColumn Header="Name" Width="120"
DisplayMemberBinding="{Binding Name}" />
<GridViewColumn Header="Age" Width="50"
DisplayMemberBinding="{Binding Age}" />
<GridViewColumn Header="Mail" Width="150">
<GridViewColumn.CellTemplate>
<DataTemplate>
<TextBlock Text="{Binding Mail}"
TextDecorations="Underline" Foreground="Blue" Cursor="Hand" />
</DataTemplate>
</GridViewColumn.CellTemplate>
</GridViewColumn>
</GridView>
</ListView.View>
</ListView>
</Grid>
Please notice: The Code-behind code for this example is the same as the one used for the first example in
this article.
We specify a custom CellTemplate for the last column, where we would like to do some special formatting
for the e-mail addresses. For the other columns, where we just want basic text output, we stick with the
DisplayMemberBinding, simply because it requires way less markup.
Let's try changing that to left aligned column names. Unfortunately, there are no direct properties on the
GridViewColumn to control this, but fortunately that doesn't mean that it can't be changed.
Using a Style, targeted at the GridViewColumHeader, which is the element used to show the header of a
GridViewColumn, we can change the HorizontalAlignment property. In this case it defaults to Center, but
we can change it to Left, to accomplish what we want:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewGridViewSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewGridViewSample" Height="200" Width="400">
<Grid>
<ListView Margin="10" Name="lvUsers">
<ListView.Resources>
<Style TargetType="{x:Type GridViewColumnHeader}">
<Setter Property="HorizontalContentAlignment"
Value="Left" />
</Style>
</ListView.Resources>
<ListView.View>
<GridView>
The part that does all the work for us, is the Style defined in the Resources of the ListView:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewGridViewSample"
xmlns
In case you want another alignment, e.g. right alignment, you just change the value of the style like this:
For this article, I've borrowed the sample code from a previous article and then expanded on it to support
grouping. It looks like this:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewGroupSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewGroupSample" Height="300" Width="300">
<Grid Margin="10">
<ListView Name="lvUsers">
<ListView.View>
<GridView>
<GridViewColumn Header="Name" Width="120"
DisplayMemberBinding="{Binding Name}" />
<GridViewColumn Header="Age" Width="50"
DisplayMemberBinding="{Binding Age}" />
</GridView>
</ListView.View>
<ListView.GroupStyle>
<GroupStyle>
<GroupStyle.HeaderTemplate>
<DataTemplate>
<TextBlock FontWeight="Bold" FontSize
="14" Text="{Binding Name}"/>
</DataTemplate>
</GroupStyle.HeaderTemplate>
</GroupStyle>
</ListView.GroupStyle>
</ListView>
</Grid>
</Window>
using System;
namespace WpfTutorialSamples.ListView_control
{
public partial class ListViewGroupSample : Window
{
public ListViewGroupSample()
{
InitializeComponent();
List<User> items = new List<User>();
items.Add(new User() { Name = "John Doe", Age = 42, Sex =
SexType.Male });
items.Add(new User() { Name = "Jane Doe", Age = 39, Sex =
SexType.Female });
items.Add(new User() { Name = "Sammy Doe", Age = 13, Sex
= SexType.Male });
lvUsers.ItemsSource = items;
CollectionView view =
(CollectionView)CollectionViewSource.GetDefaultView(lvUsers.ItemsSource)
;
PropertyGroupDescription groupDescription = new
PropertyGroupDescription("Sex");
view.GroupDescriptions.Add(groupDescription);
}
}
In XAML, I have added a GroupStyle to the ListView, in which I define a template for the header of each
group. It consists of a TextBlock control, where I've used a slightly larger and bold text to show that it's a
group - as we'll see later on, this can of course be customized a lot more. The TextBlock Text property is
bound to a Name property, but please be aware that this is not the Name property on the data object
(in this case the User class). Instead, it is the name of the group, as assigned by WPF, based on the
property we use to divide the objects into groups.
In Code-behind, we do the same as we did before: We create a list and add some User objects to it and
then we bind the list to the ListView - nothing new there, except for the new Sex property that I've added,
which tells whether the user is male or female.
After assigning an ItemsSource, we use this to get a CollectionView that the ListView creates for us. This
specialized View instance contains a lot of possibilities, including the ability to group the items. We use this
by adding a so-called PropertyGroupDescription to the GroupDescriptions of the view. This basically tells
WPF to group by a specific property on the data objects, in this case the Sex property.
It might look a bit cumbersome, but the principles used are somewhat simple and you will see them in
other situations when you customize the WPF controls. Here's the code:
<Window x:Class
<ListView.GroupStyle>
<GroupStyle>
<GroupStyle.ContainerStyle>
<Style TargetType="{x:Type GroupItem}">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate>
<Expander IsExpanded
="True">
<Expander.Header>
<StackPanel
Orientation="Horizontal">
<
TextBlock Text="{Binding Name}" FontWeight="Bold" Foreground="Gray"
FontSize="22" VerticalAlignment="Bottom" />
<
TextBlock Text="{Binding ItemCount}" FontSize="22" Foreground="Green"
FontWeight="Bold" FontStyle="Italic" Margin="10,0,0,0" VerticalAlignment
="Bottom" />
<
TextBlock Text=" item(s)" FontSize="22" Foreground="Silver" FontStyle
="Italic" VerticalAlignment="Bottom" />
</StackPanel
>
The Code-behind is exactly the same as used in the first example - feel free to scroll up and grab it.
Now our groups look a bit more exciting, and they even include an expander button, that will toggle the
visibility of the group items when you click it (that's why the single female user is not visible on the
screenshot - I collapsed that particular group). By using the ItemCount property that the group exposes, we
can even show how many items each group currently consists of.
As you can see, it requires a bit more markup than we're used to, but this example also goes a bit beyond
what we usually do, so that seems fair. When you read through the code, you will quickly realize that many
of the lines are just common elements like style and template.
1.16.6.2. Summary
Adding grouping to the WPF ListView is very simple - all you need is a GroupStyle with a HeaderTemplate,
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewSortingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewSortingSample" Height="200" Width="300">
<Grid Margin="10">
<ListView Name="lvUsers">
<ListView.View>
<GridView>
<GridViewColumn Header="Name" Width="120"
DisplayMemberBinding="{Binding Name}" />
<GridViewColumn Header="Age" Width="50"
DisplayMemberBinding="{Binding Age}" />
</GridView>
</ListView.View>
</ListView>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Windows;
using System.Windows.Data;
namespace WpfTutorialSamples.ListView_control
{
public partial class ListViewSortingSample : Window
{
public ListViewSortingSample()
{
InitializeComponent();
List<User> items = new List<User>();
items.Add(new User() { Name = "John Doe", Age = 42 });
CollectionView view =
(CollectionView)CollectionViewSource.GetDefaultView(lvUsers.ItemsSource)
;
view.SortDescriptions.Add(new SortDescription("Age",
ListSortDirection.Ascending));
}
}
The XAML looks just like a previous example, where we simply have a couple of columns for displaying
information about the user - nothing new here.
In the Code-behind, we once again create a list of User objects, which we then assign as the ItemsSource
of the ListView. Once we've done that, we use the ItemsSource property to get the CollectionView instance
that the ListView automatically creates for us and which we can use to manipulate how the ListView shows
our objects.
With the view object in our hand, we add a new SortDescription to it, specifying that we want our list sorted
CollectionView view =
(CollectionView)CollectionViewSource.GetDefaultView(lvUsers.ItemsSource)
;
view.SortDescriptions.Add(new SortDescription("Age",
ListSortDirection.Ascending));
view.SortDescriptions.Add(new SortDescription("Name",
ListSortDirection.Ascending));
Now the view will be sorted using age first, and when two identical values are found, the name will be used
as a secondary sorting parameter.
1.16.7.2. Summary
It's very easy to sort the contents of a ListView, as seen in the above examples, but so far, all the sorting is
decided by the programmer and not the end-user. In the next article I'll give you a how-to article showing
you how to let the user decide the sorting by clicking on the columns, as seen in Windows.
In this how-to article, I'll give you a practical solution that gives us all of the above, but please bear in mind
that some of the code here goes a bit beyond what we have learned so far - that's why it has the "how-to"
label.
This article builds upon the previous one, but I'll still explain each part as we go along. Here's our goal - a
ListView with column sorting, including visual indication of sort field and direction. The user simply clicks a
column to sort by and if the same column is clicked again, the sort direction is reversed. Here's how it
looks:
<Window x:Class
="WpfTutorialSamples.ListView_control.ListViewColumnSortingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ListViewColumnSortingSample" Height="200" Width="350">
<Grid Margin="10">
<ListView Name="lvUsers">
<ListView.View>
Notice how I have specified headers for each of the columns using an actual GridViewColumnHeader
element instead of just specifying a string. This is done so that I may set additional properties, in this case
the Tag property as well as the Click event.
The Tag property is used to hold the field name that will be used to sort by, if this particular column is
clicked. This is done in the lvUsersColumnHeader_Click event that each of the columns subscribes to.
That was the key concepts of the XAML. Besides that, we bind to our Code-behind properties Name, Age
and Sex, which we'll discuss now.
namespace WpfTutorialSamples.ListView_control
{
public partial class ListViewColumnSortingSample : Window
{
private GridViewColumnHeader listViewSortCol = null;
private SortAdorner listViewSortAdorner = null;
public ListViewColumnSortingSample()
{
InitializeComponent();
List<User> items = new List<User>();
items.Add(new User() { Name = "John Doe", Age = 42, Sex =
SexType.Male });
items.Add(new User() { Name = "Jane Doe", Age = 39, Sex =
SexType.Female });
items.Add(new User() { Name = "Sammy Doe", Age = 13, Sex
= SexType.Male });
items.Add(new User() { Name = "Donna Doe", Age = 13, Sex
= SexType.Female });
lvUsers.ItemsSource = items;
}
listViewSortCol = column;
listViewSortAdorner = new SortAdorner(listViewSortCol,
newDir);
AdornerLayer.GetAdornerLayer(listViewSortCol).Add(listViewSortAdorner);
lvUsers.Items.SortDescriptions.Add(new
SortDescription(sortBy, newDir));
}
}
drawingContext.Pop();
}
}
}
Allow me to start from the bottom and then work my way up while explaining what happens. The last class
in the file is an Adorner class called SortAdorner. All this little class does is to draw a triangle, either
pointing up or down, depending on the sort direction. WPF uses the concept of adorners to allow you to
paint stuff over other controls, and this is exactly what we want here: The ability to draw a sorting triangle
on top of our ListView column header.
The SortAdorner works by defining two Geometry objects, which are basically used to describe 2D
shapes - in this case a triangle with the tip pointing up and one with the tip pointing down. The
Geometry.Parse() method uses the list of points to draw the triangles, which will be explained more
The SortAdorner is aware of the sort direction, because it needs to draw the proper triangle, but is not
aware of the field that we order by - this is handled in the UI layer.
The User class is just a basic information class, used to contain information about a user. Some of this
information is used in the UI layer, where we bind to the Name, Age and Sex properties.
In the Window class, we have two methods: The constructor where we build a list of users and assign it to
the ItemsSource of our ListView, and then the more interesting click event handler that will be hit when the
user clicks a column. In the top of the class, we have defined two private variables: listViewSortCol and
listViewSortAdorner. These will help us keep track of which column we're currently sorting by and the
adorner we placed to indicate it.
In the lvUsersColumnHeader_Click event handler, we start off by getting a reference to the column that the
user clicked. With this, we can decide which property on the User class to sort by, simply by looking at the
Tag property that we defined in XAML. We then check if we're already sorting by a column - if that is the
case, we remove the adorner and clear the current sort descriptions.
After that, we're ready to decide the direction. The default is ascending, but we do a check to see if we're
already sorting by the column that the user clicked - if that is the case, we change the direction to
descending.
In the end, we create a new SortAdorner, passing in the column that it should be rendered on, as well as
the direction. We add this to the AdornerLayer of the column header, and at the very end, we add a
SortDescription to the ListView, to let it know which property to sort by and in which direction.
1.16.8.3. Summary
Congratulations, you now have a fully sortable ListView with visual indication of sort column and direction.
In case you want to know more about some of the concepts used in this article, like data binding, geometry
or ListViews in general, then please check out some of the other articles, where each of the subjects are
covered in depth.
Filtering is actually quite easy to do, so let's jump straight into an example, and then we'll discuss it
afterwards:
<Window x:Class="WpfTutorialSamples.ListView_control.FilteringSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="FilteringSample" Height="200" Width="300">
<DockPanel Margin="10">
<TextBox DockPanel.Dock="Top" Margin="0,0,0,10" Name
="txtFilter" TextChanged="txtFilter_TextChanged" />
<ListView Name="lvUsers">
<ListView.View>
<GridView>
<GridViewColumn Header="Name" Width="120"
DisplayMemberBinding="{Binding Name}" />
<GridViewColumn Header="Age" Width="50"
DisplayMemberBinding="{Binding Age}" />
</GridView>
</ListView.View>
</ListView>
</DockPanel>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
using System.Windows.Data;
namespace WpfTutorialSamples.ListView_control
{
public partial class FilteringSample : Window
{
public FilteringSample()
CollectionView view =
(CollectionView)CollectionViewSource.GetDefaultView(lvUsers.ItemsSource)
;
view.Filter = UserFilter;
}
CollectionViewSource.GetDefaultView(lvUsers.ItemsSource).Refresh();
}
}
The XAML part is pretty simple: We have a TextBox, where the user can enter a search string, and then a
ListView to show the result in.
In Code-behind, we start off by adding some User objects to the ListView, just like we did in previous
examples. The interesting part happens in the last two lines of the constructor, where we obtain a reference
to the CollectionView instance for the ListView and then assign a delegate to the Filter property. This
delegate points to the function called UserFilter, which we have implemented just below. It takes each item
as the first (and only) parameter and then returns a boolean value that indicates whether or not the given
item should be visible on the list.
In the UserFilter() method, we take a look at the TextBox control (txtFilter), to see if it contains any text - if
it does, we use it to check whether or not the name of the User (which is the property we have decided to
filter on) contains the entered string, and then return true or false depending on that. If the TextBox is
empty, we return true, because in that case we want all the items to be visible.
The txtFilter_TextChanged event is also important. Each time the text changes, we get a reference to the
View object of the ListView and then call the Refresh() method on it. This ensures that the Filter delegate is
called each time the user changes the value of the search/filter string text box.
1.16.9.1. Summary
This was a pretty simple implementation, but since you get access to each item, in this case of the User
class, you can do any sort of custom filtering that you like, since you have access to all of the data about
each of the items in the list. For instance, the above example could easily be changed to filter on age, by
looking at the Age property instead of the Name property, or you could modify it to look at more than one
property, e.g. to filter out users with an age below X AND a name that doesn't contain "Y".
Just like with the ListView control, the TreeView control does have its own item type, the TreeViewItem,
which you can use to populate the TreeView. If you come from the WinForms world, you will likely start by
generating TreeViewItem's and adding them to the Items property, and this is indeed possible. But since
this is WPF, the preferred way is to bind the TreeView to a hierarchical data structure and then use an
appropriate template to render the content.
We'll show you how to do it both ways, and while the good, old WinForms inspired way might seem like the
easy choice at first, you should definitely give the WPF way a try - in the long run, it offers more flexibility
and will fit in better with the rest of the WPF code you write.
1.17.1.2. Summary
The WPF TreeView is indeed a complex control. In the first example, which we'll get into already in the
next chapter, it might seem simple, but once you dig deeper, you'll see the complexity. Fortunately, the
WPF TreeView control rewards you with great usability and flexibility. To show you all of them, we have
dedicated an entire category to all the TreeView articles. Click on to the next one to get started.
<Window x:Class="WpfTutorialSamples.TreeView_control.TreeViewSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TreeViewSample" Height="200" Width="250">
<Grid Margin="10">
<TreeView>
<TreeViewItem Header="Level 1" IsExpanded="True">
<TreeViewItem Header="Level 2.1" />
<TreeViewItem Header="Level 2.2" IsExpanded="True">
<TreeViewItem Header="Level 3.1" />
<TreeViewItem Header="Level 3.2" />
</TreeViewItem>
<TreeViewItem Header="Level 2.3" />
</TreeViewItem>
</TreeView>
</Grid>
</Window>
We simply declare the TreeViewItem objects directly in the XAML, in the same structure that we want to
display them in, where the first tag is a child of the TreeView control and its child objects are also child tags
to its parent object. To specify the text we want displayed for each node, we use theHeader property. By
default, a TreeViewItem is not expanded, but to show you the structure of the example, I have used the
IsExpanded property to expand the two parent items.
One of the common requests from people coming from WinForms or even other UI libraries is the ability to
show an image next to the text label of a TreeView item. This is very easy to do with WinForms, because
the TreeView is built exactly for this scenario. With the WPF TreeView, it's a bit more complex, but you're
rewarded with a lot more flexibility than you could ever get from the WinForms TreeView. Here's an
example of it:
<Window x:Class
="WpfTutorialSamples.TreeView_control.TreeViewCustomItemsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TreeViewCustomItemsSample" Height="200" Width="250">
<Grid Margin="10">
<TreeView>
<TreeViewItem IsExpanded="True">
<TreeViewItem.Header>
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/bullet_blue.png" />
<TextBlock Text="Level 1 (Blue)" />
</StackPanel>
</TreeViewItem.Header>
<TreeViewItem>
<TreeViewItem.Header>
<StackPanel Orientation="Horizontal">
<TextBlock Text="Level 2.1"
Foreground="Blue" />
</StackPanel>
</TreeViewItem.Header>
</TreeViewItem>
<TreeViewItem IsExpanded="True">
<TreeViewItem.Header>
<StackPanel Orientation="Horizontal">
1.17.2.2. Summary
While it is entirely possible to define an entire TreeView just using markup, as we did in the above
examples, it's not the best approach in most situations, and while you could do it from Code-behind
instead, this would have resulted in even more lines of code. Once again the solution is data binding,
which we'll look into in the next chapters.
<Window x:Class
="WpfTutorialSamples.TreeView_control.TreeViewDataBindingSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:self="clr-namespace:WpfTutorialSamples.TreeView_control"
Title="TreeViewDataBindingSample" Height="150" Width="200">
<Grid Margin="10">
<TreeView Name="trvMenu">
<TreeView.ItemTemplate>
<HierarchicalDataTemplate DataType="{x:Type
self:MenuItem}" ItemsSource="{Binding Items}">
<TextBlock Text="{Binding Title}" />
</HierarchicalDataTemplate>
</TreeView.ItemTemplate>
</TreeView>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
using System.IO;
using System.Collections.ObjectModel;
namespace WpfTutorialSamples.TreeView_control
{
public partial class TreeViewDataBindingSample : Window
{
public TreeViewDataBindingSample()
{
In the XAML markup, I have specified a HierarchicalDataTemplate for the ItemTemplate of the TreeView. I
instruct it to use the Items property for finding child items, by setting the ItemsSource property of the
template, and inside of it I define the actual template, which for now just consists of a TextBlock bound to
This first example was very simple, in fact so simple that we might as well have just added the TreeView
items manually, instead of generating a set of objects and then binding to them. However, as soon as
things get a bit more complicated, the advantages of using data bindings gets more obvious.
<Window x:Class
="WpfTutorialSamples.TreeView_control.TreeViewMultipleTemplatesSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:self="clr-namespace:WpfTutorialSamples.TreeView_control"
Title="TreeViewMultipleTemplatesSample" Height="200" Width
="250">
<Grid Margin="10">
<TreeView Name="trvFamilies">
<TreeView.Resources>
<HierarchicalDataTemplate DataType="{x:Type
self:Family}" ItemsSource="{Binding Members}">
<StackPanel Orientation="Horizontal">
<Image Source
="/WpfTutorialSamples;component/Images/group.png" Margin="0,0,5,0" />
<TextBlock Text="{Binding Name}" />
<TextBlock Text=" [" Foreground="Blue" />
<TextBlock Text="{Binding Members.Count}"
Foreground="Blue" />
<TextBlock Text="]" Foreground="Blue" />
</StackPanel>
</HierarchicalDataTemplate>
<DataTemplate DataType="{x:Type self:FamilyMember}">
<StackPanel Orientation="Horizontal">
<Image Source
using System;
using System.Collections.Generic;
using System.Windows;
using System.Collections.ObjectModel;
namespace WpfTutorialSamples.TreeView_control
{
public partial class TreeViewMultipleTemplatesSample : Window
{
public TreeViewMultipleTemplatesSample()
{
InitializeComponent();
trvFamilies.ItemsSource = families;
}
}
The template defined for the FamilyMember type is a regular DataTemplate, since this type doesn't have
any child members. However, if we had wanted each FamilyMember to keep a collection of their children
and perhaps their children's children, then we would have used a hierarchical template instead.
In both templates, we use an image representing either a family or a family member, and then we show
some interesting data about it as well, like the amount of family members or the person's age.
In the code-behind, we simply create two Family instances, fill each of them with a set of members, and
then add each of the families to a list, which is then used as the items source for the TreeView.
1.17.3.3. Summary
Using data binding, the TreeView is very customizable and with the ability to specify multiple templates for
rendering different data types, the possibilities are almost endless.
Lots of solutions exists to handle this, ranging from "hacks" where you use the item generators of the
TreeView to get the underlying TreeViewItem, where you can control the IsExpanded and IsSelected
properties, to much more advanced MVVM-inspired implementations. In this article I would like to show you
a solution that lies somewhere in the middle, making it easy to implement and use, while still not being a
complete hack.
You could easily implement these two properties on all of your objects, but it's much easier to inherit them
from a base object. If this is not feasible for your solution, you could create an interface for it and then
implement this instead, to establish a common ground. For this example, I've chosen the base class
method, because it allows me to very easily get the same functionality for my other objects. Here's the
code:
<Window x:Class
="WpfTutorialSamples.TreeView_control.TreeViewSelectionExpansionSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TreeViewSelectionExpansionSample" Height="200" Width
="300">
<DockPanel Margin="10">
<WrapPanel Margin="0,10,0,0" DockPanel.Dock="Bottom"
HorizontalAlignment="Center">
<Button Name="btnSelectNext" Click="btnSelectNext_Click"
Width="120">Select next</Button>
<Button Name="btnToggleExpansion" Click
="btnToggleExpansion_Click" Width="120" Margin="10,0,0,0">Toggle
expansion</Button>
</WrapPanel>
using System;
using System.Collections.Generic;
using System.Windows;
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Windows.Controls;
namespace WpfTutorialSamples.TreeView_control
{
public partial class TreeViewSelectionExpansionSample : Window
{
public TreeViewSelectionExpansionSample()
{
InitializeComponent();
persons.Add(person1);
persons.Add(person2);
persons.Add(person3);
person2.IsExpanded = true;
person2.IsSelected = true;
trvPersons.ItemsSource = persons;
}
In the main Window class I simply create a range of persons, while adding children to some of them. I add
the persons to a list, which I assign as the ItemsSource of the TreeView, which, with a bit of help from the
defined template, renders them the way they are shown on the screenshot.
The most interesting part happens when I set the IsExpanded and IsSelected properties on the person2
object. This is what causes the second person (Jane Doe) to be initially selected and expanded, as shown
on the screenshot. We also use these two properties on the Person objects (inherited from the
TreeViewItemBase class) in the event handlers for the two test buttons (please bear in mind that, to keep
the code as small and simple as possible, the selection button only works for the top level items).
1.17.4.4. Summary
By creating and implementing a base class for the objects that you wish to use and manipulate within a
TreeView, and using the gained properties in the ItemContainerStyle, you make it a lot easier to work with
selections and expansion states. There are many solutions to tackle this problem with, and while this
should do the trick, you might be able to find a solution that fits your needs better. As always with
programming, it's all about using the right tool for the job at hand.
Each drive on your Windows computer has a range of child folders, and each of those child folders have
child folders beneath them and so on. Looping through each drive and each drives child folders could
become extremely time consuming and your TreeView would soon consist of a lot of nodes, with a high
percentage of them never being needed. This is the perfect task for a lazy-loaded TreeView, where child
folders are only loaded on demand.
To achieve this, we simply add a dummy folder to each drive or child folder, and then when the user
expands it, we remove the dummy folder and replace it with the actual values. This is how our application
looks when it starts - by that time, we have only obtained a list of available drives on the computer:
You can now start expanding the nodes, and the application will automatically load the sub folders. If a
folder is empty, it will be shown as empty once you try to expand it, as it can be seen on the next
screenshot:
<Window x:Class="WpfTutorialSamples.TreeView_control.LazyLoadingSample"
using System;
using System.IO;
using System.Windows;
using System.Windows.Controls;
namespace WpfTutorialSamples.TreeView_control
{
public partial class LazyLoadingSample : Window
{
public LazyLoadingSample()
{
InitializeComponent();
DriveInfo[] drives = DriveInfo.GetDrives();
foreach(DriveInfo driveInfo in drives)
trvStructure.Items.Add(CreateTreeItem(driveInfo));
The XAML is very simple and only one interesting detail is present: The way we subscribe to the
Expanded event of TreeViewItem's. Notice that this is indeed the TreeViewItem and not the TreeView itself,
but because the event bubbles up, we are able to just capture it in one place for the entire TreeView,
instead of having to subscribe to it for each item we add to the tree. This event gets called each time an
item is expanded, which we need to be aware of to load its child items on demand.
Next up is the TreeViewItem_Expanded event. As already mentioned, this event is raised each time a
TreeView item is expanded, so the first thing we do is to check whether this item has already been loaded,
by checking if the child items currently consists of only one item, which is a string - if so, we have found the
"Loading..." child item, which means that we should now load the actual contents and replace the
placeholder item with it.
We now use the items Tag property to get a reference to the DriveInfo or DirectoryInfo instance that the
current item represents, and then we get a list of child directories, which we add to the clicked item, once
again using the CreateTreeItem() method. Notice that the loop where we add each child folder is in a
try..catch block - this is important, because some paths might not be accessible, usually for security
reasons. You could grab the exception and use it to reflect this in the interface in one way or another.
1.17.5.1. Summary
By subscribing to the Expanded event, we can easily create a lazy-loaded TreeView, which can be a much
better solution than a statically created one in several situations.
The most common usage for the DataGrid is in combination with a database, but like most WPF controls, it
works just as well with an in-memory source, like a list of objects. Since it's a lot easier to demonstrate,
we'll mostly be using the latter approach in this tutorial.
<Window x:Class
="WpfTutorialSamples.DataGrid_control.SimpleDataGridSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SimpleDataGridSample" Height="180" Width="300">
<Grid Margin="10">
<DataGrid Name="dgSimple"></DataGrid>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.DataGrid_control
{
public partial class SimpleDataGridSample : Window
{
public SimpleDataGridSample()
{
InitializeComponent();
dgSimple.ItemsSource = users;
}
}
That's really all you need to start using the DataGrid. The source could just as easily have been a
database table/view or even an XML file - the DataGrid is not picky about where it gets its data from.
If you click inside one of the cells, you can see that you're allowed to edit each of the properties by default.
As a nice little bonus, you can try clicking one of the column headers - you will see that the DataGrid
supports sorting right out of the box!
The last and empty row will let you add to the data source, simply by filling out the cells.
However, in some situations you might want to manually define the columns shown, either because you
dont want all the properties/columns of the data source, or because you want to be in control of which inline
editors are used.
•
DataGridTextColumn
•
DataGridCheckBoxColumn
•
DataGridComboBoxColumn
•
DataGridHyperlinkColumn
•
DataGridTemplateColumn
Especially the last one, the DataGridTemplateColumn, is interesting. It allows you to define any kind of
content, which opens up the opportunity to use custom controls, either from the WPF library or even your
own or 3rd party controls. Here's an example:
<Window x:Class
="WpfTutorialSamples.DataGrid_control.DataGridColumnsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataGridColumnsSample" Height="200" Width="300">
<Grid Margin="10">
<DataGridTemplateColumn Header="Birthday">
<DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<DatePicker SelectedDate="{Binding
Birthday}" BorderThickness="0" />
</DataTemplate>
</DataGridTemplateColumn.CellTemplate>
</DataGridTemplateColumn>
</DataGrid.Columns>
</DataGrid>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.DataGrid_control
{
public partial class DataGridColumnsSample : Window
{
public DataGridColumnsSample()
{
InitializeComponent();
dgUsers.ItemsSource = users;
In the markup, I have added the AutoGenerateColumns property on the DataGrid, which I have set to
false, to get control of the columns used. As you can see, I have left out the ID column, as I decided that I
didn't care for it for this example. For the Name property, I've used a simple text based column, so the most
interesting part of this example comes with the Birthday column, where I've used a
DataGridTemplateColumn with a DatePicker control inside of it. This allows the end-user to pick the date
from a calendar, instead of having to manually enter it, as you can see on the screenshot.
1.18.2.2. Summary
By turning off automatically generated columns using the AutoGenerateColumns property, you get full
control of which columns are shown and how their data should be viewed and edited. As seen by the
example of this article, this opens up for some pretty interesting possibilities, where you can completely
customize the editor and thereby enhance the end-user experience.
<Window x:Class
="WpfTutorialSamples.DataGrid_control.DataGridDetailsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataGridDetailsSample" Height="200" Width="400">
<Grid Margin="10">
<DataGrid Name="dgUsers" AutoGenerateColumns="False">
<DataGrid.Columns>
<DataGridTextColumn Header="Name" Binding="{Binding
Name}" />
<DataGridTextColumn Header="Birthday" Binding="
{Binding Birthday}" />
</DataGrid.Columns>
<DataGrid.RowDetailsTemplate>
<DataTemplate>
<TextBlock Text="{Binding Details}" Margin="10"
/>
</DataTemplate>
</DataGrid.RowDetailsTemplate>
</DataGrid>
</Grid>
</Window>
using System;
using System.Collections.Generic;
using System.Windows;
namespace WpfTutorialSamples.DataGrid_control
{
public partial class DataGridDetailsSample : Window
{
public DataGridDetailsSample()
{
InitializeComponent();
dgUsers.ItemsSource = users;
}
}
As you can see, I have expanded the example from previous chapters with a new property on the User
class: The Description property. It simply returns a bit of information about the user in question, for our
details row.
In the markup, I have defined a couple of columns and then I use the RowDetailsTemplate to specify a
template for the row details. As you can see, it works much like any other WPF template, where I use a
DataTemplate with one or several controls inside of it, along with a standard binding against a property on
the data source, in this case the Description property.
If you set it to Collapsed, all details will be invisible all the time.
As you can see from the code listing, it's mostly about expanding the details template into using a panel,
which in turn can host more panels and/or controls. Using a Grid panel, we can get the tabular look of the
user data, and an Image control allows us to show a picture of the user (which you should preferably load
from a locale resource and not a remote one, like I do in the example - and sorry for being too lazy to find a
matching image of Jane and Sammy Doe).
<Window x:Class
="WpfTutorialSamples.DataGrid_control.DataGridDetailsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DataGridDetailsSample" Height="300" Width="300">
<Grid Margin="10">
<DataGrid Name="dgUsers" AutoGenerateColumns="False">
<DataGrid.Columns>
<DataGridTextColumn Header="Name" Binding="{Binding
Name}" />
<DataGridTextColumn Header="Birthday" Binding="
{Binding Birthday}" />
</Grid>
</DockPanel>
</DataTemplate>
</DataGrid.RowDetailsTemplate>
</DataGrid>
</Grid>
</Window>
using System;
using System.Collections.Generic;
namespace WpfTutorialSamples.DataGrid_control
{
public partial class DataGridDetailsSample : Window
{
public DataGridDetailsSample()
{
InitializeComponent();
List<User> users = new List<User>();
users.Add(new User() { Id = 1, Name = "John Doe",
Birthday = new DateTime(1971, 7, 23), ImageUrl = "http://www.wpf-
tutorial.com/images/misc/john_doe.jpg" });
users.Add(new User() { Id = 2, Name = "Jane Doe",
Birthday = new DateTime(1974, 1, 17) });
users.Add(new User() { Id = 3, Name = "Sammy Doe",
Birthday = new DateTime(1991, 9, 2) });
dgUsers.ItemsSource = users;
}
}
1.18.3.3. Summary
Being able to show details for a DataGrid row is extremely useful, and with the WPF DataGrid it's both
easy and highly customizable, as you can see from the examples provided in this tutorial.
But what happens when you want to use the exact same font size and color on three different TextBlock
controls? You can copy/paste the desired properties to each of them, but what happens when three
controls becomes 50 controls, spread out over several windows? And what happens when you realize that
the font size should be 14 instead of 12?
WPF introduces styling, which is to XAML what CSS is to HTML. Using styles, you can group a set of
properties and assign them to specific controls or all controls of a specific type, and just like in CSS, a style
can inherit from another style.
<Window x:Class="WpfTutorialSamples.Styles.SimpleStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SimpleStyleSample" Height="200" Width="250">
<StackPanel Margin="10">
<StackPanel.Resources>
<Style TargetType="TextBlock">
<Setter Property="Foreground" Value="Gray" />
<Setter Property="FontSize" Value="24" />
</Style>
</StackPanel.Resources>
<TextBlock>Header 1</TextBlock>
<TextBlock>Header 2</TextBlock>
<TextBlock Foreground="Blue">Header 3</TextBlock>
</StackPanel>
</Window>
Notice that the last TextBlock is blue instead of gray. I did that to show you that while a control might get
styling from a designated style, you are completely free to override this locally on the control - values
defined directly on the control will always take precedence over style values.
1.19.1.2. Summary
WPF styles make it very easy to create a specific look and then use it for several controls, and while this
first example was very local, I will show you how to create global styles in the next chapters.
<Window x:Class="WpfTutorialSamples.Styles.ControlSpecificStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ControlSpecificStyleSample" Height="100" Width="300">
<Grid Margin="10">
<TextBlock Text="Style test">
<TextBlock.Style>
<Style>
<Setter Property="TextBlock.FontSize" Value
="36" />
</Style>
</TextBlock.Style>
</TextBlock>
</Grid>
</Window>
In this example, the style only affects this specific TextBlock control, so why bother? Well, in this case, it
makes no sense at all. I could have replaced all that extra markup with a single FontSize property on the
TextBlock control, but as we'll see later, styles can do a bit more than just set properties, for instance, style
triggers could make the above example useful in a real life application. However, most of the styles you'll
define will likely be in a higher scope.
<Window x:Class="WpfTutorialSamples.Styles.SimpleStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SimpleStyleSample" Height="200" Width="250">
<StackPanel Margin="10">
<StackPanel.Resources>
<Style TargetType="TextBlock">
<Setter Property="Foreground" Value="Gray" />
<Setter Property="FontSize" Value="24" />
</Style>
</StackPanel.Resources>
<TextBlock>Header 1</TextBlock>
<TextBlock>Header 2</TextBlock>
<TextBlock Foreground="Blue">Header 3</TextBlock>
</StackPanel>
</Window>
This is great for the more local styling needs. For instance, it would make perfect sense to do this in a
dialog where you simply needed a set of controls to look the same, instead of setting the individual
properties on each of them.
<Window x:Class="WpfTutorialSamples.Styles.WindowWideStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WindowWideStyleSample" Height="200" Width="300">
<Window.Resources>
<Style TargetType="TextBlock">
<Setter Property="Foreground" Value="Gray" />
<Setter Property="FontSize" Value="24" />
</Style>
</Window.Resources>
<StackPanel Margin="10">
<TextBlock>Header 1</TextBlock>
<TextBlock>Header 2</TextBlock>
<TextBlock Foreground="Blue">Header 3</TextBlock>
</StackPanel>
</Window>
As you can see, the result is exactly the same, but it does mean that you could have controls placed
everywhere within the window and the style would still apply.
App.xaml
<Application x:Class="WpfTutorialSamples.App"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="Styles/WindowWideStyleSample.xaml">
<Application.Resources>
<Style TargetType="TextBlock">
<Setter Property="Foreground" Value="Gray" />
<Setter Property="FontSize" Value="24" />
</Style>
</Application.Resources>
</Application>
Window
<Window x:Class="WpfTutorialSamples.Styles.WindowWideStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ApplicationWideStyleSample" Height="200" Width="300">
<StackPanel Margin="10">
<TextBlock>Header 1</TextBlock>
<TextBlock>Header 2</TextBlock>
<TextBlock Foreground="Blue">Header 3</TextBlock>
</StackPanel>
</Window>
By setting the x:Key property on a style, you are telling WPF that you only want to use this style when you
explicitly reference it on a specific control. Let's try an example where this is the case:
<Window x:Class="WpfTutorialSamples.Styles.ExplicitStyleSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="ExplicitStyleSample" Height="150" Width="300">
<Window.Resources>
<Style x:Key="HeaderStyle" TargetType="TextBlock">
<Setter Property="Foreground" Value="Gray" />
<Setter Property="FontSize" Value="24" />
</Style>
</Window.Resources>
<StackPanel Margin="10">
<TextBlock>Header 1</TextBlock>
<TextBlock Style="{StaticResource HeaderStyle}">Header 2</
TextBlock>
<TextBlock>Header 3</TextBlock>
</StackPanel>
</Window>
Notice how even though the TargetType is set to TextBlock, and the style is defined for the entire window,
only the TextBlock in the middle, where I explicitly reference the HeaderStyle style, uses the style. This
allows you to define styles that target a specific control type, but only use it in the places where you need it.
<Window x:Class="WpfTutorialSamples.Styles.StyleTriggersSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleTriggersSample" Height="100" Width="300">
<Grid>
<TextBlock Text="Hello, styled world!" FontSize="28"
HorizontalAlignment="Center" VerticalAlignment="Center">
<TextBlock.Style>
<Style TargetType="TextBlock">
<Setter Property="Foreground" Value="Blue"></
Setter>
<Style.Triggers>
<Trigger Property="IsMouseOver" Value
="True">
<Setter Property="Foreground" Value
="Red" />
<Setter Property="TextDecorations"
Value="Underline" />
</Trigger>
</Style.Triggers>
</Style>
</TextBlock.Style>
</TextBlock>
</Grid>
</Window>
We define a local style for this specific TextBlock, but as shown in the previous articles, the style could
have been globally defined as well, if we wanted it to apply to all TextBlock controls in the application.
<Window x:Class="WpfTutorialSamples.Styles.StyleDataTriggerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleDataTriggerSample" Height="200" Width="200">
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center"
>
<CheckBox Name="cbSample" Content="Hello, world?" />
<TextBlock HorizontalAlignment="Center" Margin="0,20,0,0"
FontSize="48">
<TextBlock.Style>
<Style TargetType="TextBlock">
<Setter Property="Text" Value="No" />
<Setter Property="Foreground" Value="Red" />
<Style.Triggers>
<DataTrigger Binding="{Binding
ElementName=cbSample, Path=IsChecked}" Value="True">
<Setter Property="Text" Value="Yes!"
/>
<Setter Property="Foreground" Value
="Green" />
In this example, we have a CheckBox and a TextBlock. Using a DataTrigger, we bind the TextBlock to
the IsChecked property of the CheckBox. We then supply a default style, where the text is "No" and the
foreground color is red, and then, using a DataTrigger, we supply a style for when the IsChecked property
of the CheckBox is changed to True, in which case we make it green with a text saying "Yes!" (as seen on
the screenshot).
<Window x:Class="WpfTutorialSamples.Styles.StyleEventTriggerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleEventTriggerSample" Height="100" Width="300">
<Grid>
<TextBlock Name="lblStyled" Text="Hello, styled world!"
FontSize="18" HorizontalAlignment="Center" VerticalAlignment="Center">
<TextBlock.Style>
The markup might look a bit overwhelming, but if you run this sample and look at the result, you'll see that
we've actually accomplished a pretty cool animation, going both ways, in ~20 lines of XAML. As you can
see, I use an EventTrigger to subscribe to two events: MouseEnter and MouseLeave. When the mouse
enters, I make a smooth and animated transition to a FontSize of 28 pixels in 300 milliseconds. When the
mouse leaves, I change the FontSize back to 18 pixels but I do it a bit slower, just because it looks kind of
cool.
In the next article, we'll look at multi triggers, which allow us to apply styles based on multiple properties.
There are two types of multi triggers: The MultiTrigger, which just like the regular Trigger works on
dependency properties, and then the MultiDataTrigger, which works by binding to any kind of property.
Let's start with a quick example on how to use the MultiTrigger.
1.19.4.1. MultiTrigger
<Window x:Class="WpfTutorialSamples.Styles.StyleMultiTriggerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleMultiTriggerSample" Height="100" Width="250">
<Grid>
<TextBox VerticalAlignment="Center" HorizontalAlignment
="Center" Text="Hover and focus here" Width="150">
<TextBox.Style>
<Style TargetType="TextBox">
<Style.Triggers>
<MultiTrigger>
<MultiTrigger.Conditions>
<Condition Property
="IsKeyboardFocused" Value="True" />
<Condition Property
="IsMouseOver" Value="True" />
</MultiTrigger.Conditions>
<MultiTrigger.Setters>
<Setter Property="Background"
Value="LightGreen" />
</MultiTrigger.Setters>
</MultiTrigger>
</Style.Triggers>
</Style>
</TextBox.Style>
</TextBox>
</Grid>
</Window>
1.19.4.2. MultiDataTrigger
Just like a regular DataTrigger, the MultiDataTrigger is cool because it uses bindings to monitor a property.
This means that you can use all of the cool WPF binding techniques, including binding to the property of
another control etc. Let me show you how easy it is:
<Window x:Class="WpfTutorialSamples.Styles.StyleMultiDataTriggerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleMultiDataTriggerSample" Height="150" Width="200">
<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center"
>
<CheckBox Name="cbSampleYes" Content="Yes" />
<CheckBox Name="cbSampleSure" Content="I'm sure" />
<TextBlock HorizontalAlignment="Center" Margin="0,20,0,0"
FontSize="28">
<TextBlock.Style>
<Style TargetType="TextBlock">
<Setter Property="Text" Value="Unverified" />
<Setter Property="Foreground" Value="Red" />
<Style.Triggers>
<MultiDataTrigger>
<MultiDataTrigger.Conditions>
<Condition Binding="{Binding
ElementName=cbSampleYes, Path=IsChecked}" Value="True" />
<Condition Binding="{Binding
ElementName=cbSampleSure, Path=IsChecked}" Value="True" />
</MultiDataTrigger.Conditions>
<Setter Property="Text" Value
="Verified" />
In this example, I've re-created the example we used with the regular DataTrigger, but instead of binding to
just one property, I bind to the same property (IsChecked) but on two different controls. This allows us to
trigger the style only once both checkboxes are checked - if you remove a check from either one of them,
the default style will be applied instead.
1.19.4.3. Summary
As you can see, multi triggers are pretty much just as easy to use as regular triggers and they can be
extremely useful, especially when developing your own controls.
For this, we use the EnterActions and ExitActions properties, which are present in all of the trigger types
already discussed (except for the EventTrigger), both single and multiple. Here's an example:
<Window x:Class="WpfTutorialSamples.Styles.StyleTriggerEnterExitActions"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="StyleTriggerEnterExitActions" Height="200" Width="200"
UseLayoutRounding="True">
<Grid>
<Border Background="LightGreen" Width="100" Height="100"
BorderBrush="Green">
<Border.Style>
<Style TargetType="Border">
<Style.Triggers>
<Trigger Property="IsMouseOver" Value
="True">
<Trigger.EnterActions>
<BeginStoryboard>
<Storyboard>
<ThicknessAnimation
Duration="0:0:0.400" To="3" Storyboard.TargetProperty="BorderThickness"
/>
<DoubleAnimation
Duration="0:0:0.300" To="125" Storyboard.TargetProperty="Height" />
<DoubleAnimation
Duration="0:0:0.300" To="125" Storyboard.TargetProperty="Width" />
</Storyboard>
</BeginStoryboard>
</Trigger.EnterActions>
<Trigger.ExitActions>
<BeginStoryboard>
<Storyboard>
<ThicknessAnimation
Duration="0:0:0.250" To="0" Storyboard.TargetProperty="BorderThickness"
In this example, we have a green square. It has a trigger that fires once the mouse is over, in which case it
fires of several animations, all defined in the EnterActions part of the trigger. In there, we animate the
We use the ExitActions to reverse the changes we made, with animations that goes back to the default
values. We run the reversing animations slightly faster, because we can and because it looks cool.
The two states are represented on the two screenshots, but to fully appreciate the effect, you should try
running the example on your own machine, using the source code above.
1.19.5.1. Summary
Using animations with style triggers is very easy, and while we haven't fully explored all you can do with
WPF animations yet, the example used above should give you an idea on just how flexible both animations
and styles are.
The DispatcherTimer class works by specifying an interval and then subscribing to the Tick event that will
occur each time this interval is met. The DispatcherTimer is not started before you call the Start() method
or set the IsEnabled property to true.
Let's try a simple example where we use a DispatcherTimer to create a digital clock:
<Window x:Class="WpfTutorialSamples.Misc.DispatcherTimerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="DispatcherTimerSample" Height="150" Width="250">
<Grid>
<Label Name="lblTime" FontSize="48" HorizontalAlignment
="Center" VerticalAlignment="Center" />
</Grid>
</Window>
using System;
using System.Windows;
using System.Windows.Threading;
namespace WpfTutorialSamples.Misc
{
public partial class DispatcherTimerSample : Window
{
public DispatcherTimerSample()
{
InitializeComponent();
DispatcherTimer timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromSeconds(1);
timer.Tick += timer_Tick;
The XAML part is extremely simple - it's merely a centered label with a large font size, used to display the
current time.
Code-behind is where the magic happens in this example. In the constructor of the window, we create a
DispatcherTimer instance. We set the Interval property to one second, subscribe to the Tick event and
then we start the timer. In the Tick event, we simply update the label to show the current time.
Of course, the DispatcherTimer can work at smaller or much bigger intervals. For instance, you might only
want something to happen every 30 seconds or 5 minutes - just use the TimeSpan.From* methods, like
FromSeconds or FromMinutes, or create a new TimeSpan instance that completely fits your needs.
To show what the DispatcherTimer is capable of, let's try updating more frequently... A lot more frequently!
using System;
using System.Windows;
using System.Windows.Threading;
namespace WpfTutorialSamples.Misc
{
public partial class DispatcherTimerSample : Window
{
public DispatcherTimerSample()
As you can see, we now ask the DispatcherTimer to fire every millisecond! In the Tick event, we use a
custom time format string to show the milliseconds in the label as well. Now you have something that could
easily be used as a stopwatch - just add a couple of buttons to the Window and then have them call the
Stop(), Start() and Restart() methods on the timer.
1.20.1.1. Summary
There are many situations where you would need something in your application to occur at a given
interval, and using the DispatcherTimer, it's quite easy to accomplish. Just be aware that if you do
something complicated in your Tick event, it shouldn't run too often, like in the last example where the timer
ticks each millisecond - that will put a heavy strain on the computer running your application.
Also be aware that the DispatcherTimer is not 100% precise in all situations. The tick operations are
placed on the Dispatcher queue, so if the computer is under a lot of pressure, your operation might be
delayed. The .NET framework promises that the Tick event will never occur too early, but can't promise that
it won't be slightly delayed. However, for most use cases, the DispatcherTimer is more than precise
enough.
This is quite a surprise to people who are new to Windows programming, when they first do something that
takes more than a second and realize that their application actually hangs while doing so. The result is a lot
of frustrated forum posts from people who are trying to run a lengthy process while updating a progress
bar, only to realize that the progress bar is not updated until the process is done running.
The solution to all of this is the use of multiple threads, and while C# makes this quite easy to do, multi-
threading comes with a LOT of pitfalls, and for a lot of people, they are just not that comprehensible. This is
where the BackgroundWorker comes into play - it makes it simple, easy and fast to work with an extra
thread in your application.
When performing a task on a different thread, you usually have to communicate with the rest of the
application in two situations: When you want to update it to show how far you are in the process, and then
of course when the task is done and you want to show the result. The BackgroundWorker is built around
this idea, and therefore comes with the two events ProgressChanged and RunWorkerCompleted.
The third event is called DoWork and the general rule is that you can't touch anything in the UI from this
event. Instead, you call the ReportProgress() method, which in turn raises the ProgressChanged event,
from where you can update the UI. Once you're done, you assign a result to the worker and then the
RunWorkerCompleted event is raised.
So, to sum up, the DoWork event takes care of all the hard work. All of the code in there is executed on a
different thread and for that reason you are not allowed to touch the UI from it. Instead, you bring data (from
the UI or elsewhere) into the event by using the argument on the RunWorkerAsync() method, and the
resulting data out of it by assigning it to the e.Result property.
The ProgressChanged and RunWorkerCompleted events, on the other hand, are executed on the same
thread as the BackgroundWorker is created on, which will usually be the main/UI thread and therefore you
are allowed to update the UI from them. Therefore, the only communication that can be performed between
your running background task and the UI is through the ReportProgress() method.
That was a lot of theory, but even though the BackgroundWorker is easy to use, it's important to
Our sample application has two buttons: One that will perform the task synchronously (on the same
thread) and one that will perform the task with a BackgroundWorker and thereby on a different thread. This
should make it very easy to see the need for an extra thread when doing time consuming tasks. The code
looks like this:
<Window x:Class="WpfTutorialSamples.Misc.BackgroundWorkerSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="BackgroundWorkerSample" Height="300" Width="375">
<DockPanel Margin="10">
<DockPanel DockPanel.Dock="Top">
<Button Name="btnDoSynchronousCalculation" Click
="btnDoSynchronousCalculation_Click" DockPanel.Dock="Left"
HorizontalAlignment="Left">Synchronous (same thread)</Button>
<Button Name="btnDoAsynchronousCalculation" Click
="btnDoAsynchronousCalculation_Click" DockPanel.Dock="Right"
HorizontalAlignment="Right">Asynchronous (worker thread)</Button>
</DockPanel>
<ProgressBar DockPanel.Dock="Bottom" Height="18" Name
="pbCalculationProgress" />
</DockPanel>
</Window>
using System;
using System.ComponentModel;
using System.Windows;
namespace WpfTutorialSamples.Misc
int result = 0;
for(int i = 0; i < max; i++)
{
if(i % 42 == 0)
{
lbResults.Items.Add(i);
result++;
}
System.Threading.Thread.Sleep(1);
pbCalculationProgress.Value = Convert.ToInt32(((
double)i / max) * 100);
}
MessageBox.Show("Numbers between 0 and 10000 divisible by
7: " + result);
}
}
e.Result = result;
}
The XAML part consists of a couple of buttons, one for running the process synchronously (on the UI
thread) and one for running it asynchronously (on a background thread), a ListBox control for showing all
the calculated numbers and then a ProgressBar control in the bottom of the window to show... well, the
progress!
In Code-behind, we start off with the synchronous event handler. As mentioned, it loops from 0 to 10.000
with a small delay in each iteration, and if the number is divisible with the number 7, then we add it to the
list. In each iteration we also update the ProgressBar, and once we're all done, we show a message to the
user about how many numbers were found.
If you run the application and press the first button, it will look like this, no matter how far you are in the
process:
No items on the list and, no progress on the ProgressBar, and the button hasn't even been released, which
proves that there hasn't been a single update to the UI ever since the mouse was pressed down over the
button.
Pressing the second button instead will use the BackgroundWorker approach. As you can see from the
code, we do pretty much the same, but in a slightly different way. All the hard work is now placed in the
DoWork event, which the worker calls after you run the RunWorkerAsync() method. This method takes
input from your application which can be used by the worker, as we'll talk about later.
Once all the numbers have been tested, we assign the result to the e.Result property. This will then be
carried to the RunWorkerCompleted event, where we show it to the user. This might seem a bit
cumbersome, instead of just showing it to the user as soon as the work is done, but once again, it ensures
that we don't communicate with the UI from the DoWork event, which is not allowed.
The result is, as you can see, much more user friendly:
The window no longer hangs, the button is clicked but not suppressed, the list of possible numbers is
updated on the fly and the ProgressBar is going steadily up - the interface just got a whole lot more
responsive.
The same is actually true for the ReportProgress method. Its secondary argument is called userState and
is an object type, meaning that you can pass whatever you want to the ProgressChanged method.
1.20.2.4. Summary
The BackgroundWorker is an excellent tool when you want multi-threading in your application, mainly
because it's so easy to use. In this chapter we looked at one of the things made very easy by the
BackgroundWorker, which is progress reporting, but support for cancelling the running task is very handy
as well. We'll look into that in the next chapter.
Another problem you'll face if you perform all the work on the UI thread is the fact that there's no way for
the user to cancel a running task - and why is that? Because if the UI thread is busy performing your
lengthy task, no input will be processed, meaning that no matter how hard your user hits a Cancel button or
the Esc key, nothing happens.
Fortunately for us, the BackgroundWorker is built to make it easy for you to support progress and
cancellation, and while we looked at the whole progress part in the previous chapter, this one will be all
about how to use the cancellation support. Let's jump straight to an example:
<Window x:Class
="WpfTutorialSamples.Misc.BackgroundWorkerCancellationSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="BackgroundWorkerCancellationSample" Height="120" Width
="200">
<StackPanel VerticalAlignment="Center" HorizontalAlignment="Center"
>
<TextBlock Name="lblStatus" HorizontalAlignment="Center"
Margin="0,10" FontWeight="Bold">Not running...</TextBlock>
<WrapPanel>
<Button Name="btnStart" Width="60" Margin="10,0" Click
="btnStart_Click">Start</Button>
<Button Name="btnCancel" Width="60" Click
="btnCancel_Click">Cancel</Button>
</WrapPanel>
</StackPanel>
</Window>
using System;
using System.ComponentModel;
using System.Windows;
using System.Windows.Media;
namespace WpfTutorialSamples.Misc
{
public partial class BackgroundWorkerCancellationSample : Window
public BackgroundWorkerCancellationSample()
{
InitializeComponent();
worker = new BackgroundWorker();
worker.WorkerSupportsCancellation = true;
worker.WorkerReportsProgress = true;
worker.DoWork += worker_DoWork;
worker.ProgressChanged += worker_ProgressChanged;
worker.RunWorkerCompleted += worker_RunWorkerCompleted;
}
So, the XAML is very fundamental - just a label for showing the current status and then a couple of buttons
for starting and cancelling the worker.
In Code-behind, we start off by creating the BackgroundWorker instance. Pay special attention to the
WorkerSupportsCancellation and WorkerReportsProgress properties which we set to true - without
that, an exception will be thrown if we try to use these features.
The cancel button simply calls the CancelAsync() method - this will signal to the worker that the user
would like to cancel the running process by setting the CancellationPending property to true, but that is all
you can do from the UI thread - the rest will have to be done from inside the DoWork event.
In the DoWork event, we count to 100 with a 250 millisecond delay on each iteration. This gives us a nice
Notice how I check the CancellationPending property on each iteration - if the worker is cancelled, this
property will be true and I will have the opportunity to jump out of the loop. I set the Cancel property on the
event arguments, to signal that the process was cancelled - this value is used in the
RunWorkerCompleted event to see if the worker actually completed or if it was cancelled.
In the RunWorkerCompleted event, I simply check if the worker was cancelled or not and then update the
status label accordingly.
1.20.3.1. Summary
So to sum up, adding cancellation support to your BackgroundWorker is easy - just make sure that you set
WorkerSupportsCancellation property to true and check the CancellationPending property while
performing the work. Then, when you want to cancel the task, you just have to call the CancelAsync()
method on the worker and you're done.
So while the SoundPlayer class is simple to use, it's not terribly useful. Instead, we'll be focusing on the
MediaPlayer and MediaElement classes, which allows the playback of MP3 files, but first, let's have a look
at the simplest way of playing a sound in your WPF application - the SystemSounds class.
The SystemSounds class offers several different sounds, which corresponds to the sound defined for this
event by the user in Windows, like Exclamation and Question. You can piggyback on these sounds and
settings and play them with a single line of code:
SystemSounds.Beep.Play();
Here's a complete example, where we use all of the currently available sounds:
<Window x:Class="WpfTutorialSamples.Audio_and_Video.SystemSoundsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SystemSoundsSample" Height="200" Width="150">
<StackPanel Margin="10" HorizontalAlignment="Center"
VerticalAlignment="Center">
<Button Name="btnAsterisk" Click="btnAsterisk_Click">Asterisk
</Button>
<Button Name="btnBeep" Margin="0,5" Click="btnBeep_Click">Beep
</Button>
<Button Name="btnExclamation" Click="btnExclamation_Click">
Exclamation</Button>
<Button Name="btnHand" Margin="0,5" Click="btnHand_Click">Hand
</Button>
using System;
using System.Media;
using System.Windows;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SystemSoundsSample : Window
{
public SystemSoundsSample()
{
InitializeComponent();
}
There are of course several limitations to using this approach. First of all, you only get access to these five
sounds, and second of all, the user may have disabled them in Windows, in which case the expected
sound will be replaced with silence. On the other hand, if you only want to use these sounds the same way
that Windows does, it makes it extremely easy to produce a sound for warnings, questions etc. In that case,
it's a good thing that your application will respect the user's choice of silence.
Playing an MP3 file with the MediaPlayer class is very simple, as we'll see in this next example:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.MediaPlayerAudioSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MediaPlayerAudioSample" Height="100" Width="200">
<Grid VerticalAlignment="Center" HorizontalAlignment="Center">
<Button Name="btnOpenAudioFile" Click="btnOpenAudioFile_Click"
>Open Audio file</Button>
using System;
using System.Windows;
using System.Windows.Media;
using Microsoft.Win32;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class MediaPlayerAudioSample : Window
{
private MediaPlayer mediaPlayer = new MediaPlayer();
public MediaPlayerAudioSample()
{
InitializeComponent();
}
In this example, we just have a single button, which will show an OpenFileDialog and let you select an
Please also notice that no exception handling is done for this example, as usual to keep the example as
compact as possible, but in this case also because the Open() and Play() methods actually doesn't throw
any exceptions. Instead, you can use the MediaOpened and MediaFailed events to act when things go right
or wrong.
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.MediaPlayerAudioControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MediaPlayerAudioControlSample" Height="120" Width="300"
>
<StackPanel Margin="10">
<Label Name="lblStatus" Content="Not playing..."
HorizontalContentAlignment="Center" Margin="5" />
<WrapPanel HorizontalAlignment="Center">
<Button Name="btnPlay" Click="btnPlay_Click">Play</Button
>
<Button Name="btnPause" Margin="5,0" Click
="btnPause_Click">Pause</Button>
<Button Name="btnStop" Click="btnStop_Click">Stop</Button
>
</WrapPanel>
</StackPanel>
</Window>
using System;
using System.Windows;
using System.Windows.Media;
using System.Windows.Threading;
using Microsoft.Win32;
public MediaPlayerAudioControlSample()
{
InitializeComponent();
In this example, we have expanded our player a bit, so that it now contains a Play, Pause and Stop button,
as well as a label for showing the current playback status. The MP3 file to be played is loaded the same
way, but we do it as soon as the application starts, to keep the example simple.
Right after the MP3 is loaded, we start a timer, which ticks every second. We use this event to update the
status label, which will show the current progress as well as the entire length of the loaded file.
The three buttons each simply call a corresponding method on the MediaPlayer object - Play, Pause and
Stop.
1.21.1.4. Summary
There are several more options that you can let your user control, but I want to save that for when we have
talked about the video aspects of the MediaPlayer class - at that point, I'll do a more complete example of a
media player capable of playing both audio and video files, with more options.
I want to show you just how easy you can show video content in your WPF application, so here's a bare
minimum example:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.MediaPlayerVideoSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MediaPlayerVideoSample" Height="300" Width="300">
<Grid>
<MediaElement Source
="http://hubblesource.stsci.edu/sources/video/clips/details/images/hst_1
.mpg" />
</Grid>
</Window>
And that's it - a single line of XAML inside your window and you're displaying video (this specific video is
about the Hubble Space Telescope - more information can be found at this website) in your WPF
application.
If your window is larger than your video, this might work just fine, but perhaps you don't want any
stretching to occur? Or perhaps you want the window to adjust to fit your video's dimensions, instead of the
The first thing you need to do is to turn off stretching by setting the Stretch property to None. This will
ensure that the video is rendered in its natural size. Now if you want the window to adjust to that, it's
actually quite simple - just use the ResizeToContent property on the Window to accomplish this. Here's a
full example:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.MediaPlayerVideoSizeSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MediaPlayerVideoSizeSample" Height="500" Width="500"
SizeToContent="WidthAndHeight">
<Grid>
<MediaElement Source
="http://hubblesource.stsci.edu/sources/video/clips/details/images/hst_1
.mpg" Name="mePlayer" Stretch="None" />
</Grid>
</Window>
As you can see, despite the initial values of 500 for the Width and Height properties on the Window, the
size is adjusted (down, in this case) to match the resolution of the video.
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.MediaPlayerVideoControlSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MediaPlayerVideoControlSample" Height="300" Width="300"
>
<Grid Margin="10">
<Grid.RowDefinitions>
<RowDefinition Height="*" />
<RowDefinition Height="Auto" />
</Grid.RowDefinitions>
<MediaElement Source
="http://hubblesource.stsci.edu/sources/video/clips/details/images/hst_1
.mpg" LoadedBehavior="Manual" Name="mePlayer" />
<StackPanel Grid.Row="1">
using System;
using System.Windows;
using System.Windows.Threading;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class MediaPlayerVideoControlSample : Window
{
public MediaPlayerVideoControlSample()
{
InitializeComponent();
This example is much like the one we did in the previous article for audio, just for video in this case. We
have a bottom area with a set of buttons for controlling the playback, a label for showing the status, and
then a MediaElement control in the top area to show the actual video.
The three buttons each simply call a corresponding method on the MediaElement control - Play(), Pause()
and Stop().
1.21.2.4. Summary
Once again it's clear how easy WPF makes even advanced things like playing a video. So far, we've
worked with some basic examples, but in the next chapter, I'm going to combine all the stuff we've learned
about audio and video playback into a single, media player with a lot more functionality than we've seen so
far. Read on!
I will take the concepts used in the articles about playing audio and video and combine them with several
controls which we have already discussed previously in this article, and turn it all into a WPF Media Player.
The result will look something like this:
But that's just when it plays audio/MP3 files. Once a video is loaded, the interface automatically expands to
show the video content inside the window:
Let me tell you a bit about how this thing was built. In the end, you can of course see the entire source
code, ready for you to play with.
Notice the use of WPF commands, instead of click events for the buttons. This allows us to easily re-use
the functionality in case we want to add e.g. a main menu or a context menu with some of the same
functionality. It also makes it easier for us to toggle the functionality on and off, depending on the current
state of the player.
Also notice that we have set the MediaElement Stretch property to None, and the Window
SizeToContentMode to WidthAndHeight. This is what keeps the window to the minimum size needed to
show the interface as well as the video, if one is playing.
For showing the Volume, we've used a ProgressBar control in the lower, right corner. This doesn't
currently let the user control the volume, but merely reflects the Volume property on the MediaElement
control, through a classic data binding. We've implemented a small but neat trick for letting the user control
the volume anyway though - more on that below.
The Slider control also allows the user to skip to another part of the file, simply by dragging the "thumb" to
another location. We handle this by implementing events for DragStarted and DragCompleted - the first
one to set a variable ( userIsDraggingSlider) that tells the timer not to update the Slider while we drag,
and the second one to skip to the designated part when the user releases the mouse button.
There are CanExecute and Executed handlers for the four commands we use and especially the ones for
Pause and Stop are interesting. Since we can't get a current state from the MediaElement control, we have
to keep track of the current state ourselves. This is done with a local variable called mediaPlayerIsPlaying
, which we regularly check to see if the Pause and Stop buttons should be enabled.
The last little detail you should notice is the Grid_MouseWheel event. The main Grid covers the entire
window, so by subscribing to this event, we get notified when the user scrolls the wheel. When that
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.AudioVideoPlayerCompleteSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WPF Media Player" Height="300" Width="300"
MinWidth="300" SizeToContent="WidthAndHeight">
<Window.CommandBindings>
<CommandBinding Command="ApplicationCommands.Open" CanExecute
="Open_CanExecute" Executed="Open_Executed" />
<CommandBinding Command="MediaCommands.Play" CanExecute
="Play_CanExecute" Executed="Play_Executed" />
<CommandBinding Command="MediaCommands.Pause" CanExecute
="Pause_CanExecute" Executed="Pause_Executed" />
<CommandBinding Command="MediaCommands.Stop" CanExecute
="Stop_CanExecute" Executed="Stop_Executed" />
</Window.CommandBindings>
<Grid MouseWheel="Grid_MouseWheel">
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="*" />
<RowDefinition Height="Auto" />
</Grid.RowDefinitions>
<ToolBar>
<Button Command="ApplicationCommands.Open">
<Image Source
="/WpfTutorialSamples;component/Images/folder.png" />
</Button>
<Separator />
<Button Command="MediaCommands.Play">
<Image Source
="/WpfTutorialSamples;component/Images/control_play_blue.png" />
</Button>
<StatusBar Grid.Row="2">
<StatusBar.ItemsPanel>
<ItemsPanelTemplate>
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="*" />
<ColumnDefinition Width="Auto" />
</Grid.ColumnDefinitions>
</Grid>
</ItemsPanelTemplate>
</StatusBar.ItemsPanel>
<StatusBarItem>
<TextBlock Name="lblProgressStatus">00:00:00</
TextBlock>
</StatusBarItem>
<StatusBarItem Grid.Column="1" HorizontalContentAlignment
="Stretch">
<Slider Name="sliProgress" Thumb.DragStarted
="sliProgress_DragStarted" Thumb.DragCompleted
="sliProgress_DragCompleted" ValueChanged="sliProgress_ValueChanged" />
</StatusBarItem>
<StatusBarItem Grid.Column="2">
<ProgressBar Name="pbVolume" Width="50" Height="12"
Maximum="1" Value="{Binding ElementName=mePlayer, Path=Volume}" />
</StatusBarItem>
</StatusBar>
</Grid>
using System;
using System.Windows;
using System.Windows.Controls.Primitives;
using System.Windows.Input;
using System.Windows.Threading;
using Microsoft.Win32;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class AudioVideoPlayerCompleteSample : Window
{
private bool mediaPlayerIsPlaying = false;
private bool userIsDraggingSlider = false;
public AudioVideoPlayerCompleteSample()
{
InitializeComponent();
}
}
1.21.3.4. Summary
To transform text into spoken words, we'll be using the SpeechSynthesizer class. This class resides in
the System.Speech assembly, which we'll need to add to use it in our application. Depending on which
version of Visual Studio you use, the process looks something like this:
With the appropriate assembly added, we can now use the SpeechSynthesizer class from the
System.Speech.Synthesis namespace. With that in place, we'll kick off with yet another very simple "Hello,
world!" inspired example, this time in spoken words:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.SpeechSynthesisSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SpeechSynthesisSample" Height="150" Width="150">
<Grid>
<Button Name="btnSayIt" Click="btnSayHello_Click"
VerticalAlignment="Center" HorizontalAlignment="Center">Say hello!</
Button>
using System;
using System.Speech.Synthesis;
using System.Windows;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SpeechSynthesisSample : Window
{
public SpeechSynthesisSample()
{
InitializeComponent();
}
This is pretty much as simple as it gets, and since the screenshot really doesn't help a lot in demonstrating
speech synthesis, I suggest that you try building the example yourself, to experience it.
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.SpeechSynthesisPromptBuilderSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SpeechSynthesisPromptBuilderSample" Height="150" Width
="150">
<Grid>
<Button Name="btnSayIt" Click="btnSayHello_Click"
VerticalAlignment="Center" HorizontalAlignment="Center">Say hello!</
Button>
</Grid>
</Window>
using System;
using System.Speech.Synthesis;
using System.Windows;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SpeechSynthesisPromptBuilderSample : Window
promptBuilder.AppendTextWithHint(DateTime.Now.ToShortDateString(),
SayAs.Date);
This is where it gets interesting. Try running the example and see how nicely this works. By supplying the
SpeechSynthesizer with something more than just a text string, we can get a lot of control of how the
various parts of the sentence are spoken. In this case, the application will say the following:
Now try sending that directly to the SpeechSynthesizer and you'll probably giggle a bit of the result. What
we do instead is guide the Speak() method into how the various parts of the sentence should be used. First
of all, we ask WPF to speak the "and hello to the universe too"-part in a lower volume and a slower rate, as
if it was whispered.
The next part that doesn't just use default pronunciation is the date. We use the special SayAs
enumeration to specify that the date should be read out as an actual date and not just a set of numbers,
spaces and special characters.
We also ask that the word "all" is spoken with a stronger emphasis, to make the sentence more dynamic,
and in the end, we ask that the word "WPF" is spelled out (W-P-F) instead of being pronounced as an
actual word.
All in all, this allows us to make the SpeechSynthesizer a lot easier to understand!
1.21.4.2. Summary
Making your WPF application speak is very easy, and by using the PromptBuilder class, you can even get
a lot of control of how your words are spoken. This is a very powerful feature, but it might not be relevant to
a lot of today's applications. It's still very cool though!
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.SpeechRecognitionTextSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SpeechRecognitionTextSample" Height="200" Width="300">
<DockPanel Margin="10">
<TextBox Margin="0,10" Name="txtSpeech" AcceptsReturn="True"
/>
</DockPanel>
</Window>
using System;
using System.Speech.Recognition;
using System.Windows;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SpeechRecognitionTextSample : Window
{
public SpeechRecognitionTextSample()
{
InitializeComponent();
SpeechRecognizer speechRecognizer = new
SpeechRecognizer();
}
}
}
This is actually all you need - the text in the screenshot above was dictated through my headset and then
As soon as you initialize a SpeechRecognizer object, Windows starts up its speech recognition
application, which will do all the hard work and then send the result to the active application, in this case
ours. It looks like this:
If you haven't used speech recognition on your computer before, then Windows will take you through a
guide which will help you get started and make
some necessary adjustments.
This first example will allow you to dictate text to your application, which is great, but what about
commands? Windows and WPF will actually work together here and turn your buttons into commands,
reachable through speech, without any extra work. Here's an example:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.SpeechRecognitionTextCommandsSample
"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SpeechRecognitionTextCommandsSample" Height="200" Width
="300">
<DockPanel Margin="10">
<WrapPanel DockPanel.Dock="Top">
<Button Name="btnNew" Click="btnNew_Click">New</Button>
<Button Name="btnOpen" Click="btnOpen_Click">Open</Button
>
<Button Name="btnSave" Click="btnSave_Click">Save</Button
>
</WrapPanel>
<TextBox Margin="0,10" Name="txtSpeech" AcceptsReturn="True"
TextWrapping="Wrap" />
</DockPanel>
</Window>
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SpeechRecognitionTextCommandsSample : Window
{
public SpeechRecognitionTextCommandsSample()
{
InitializeComponent();
SpeechRecognizer recognizer = new SpeechRecognizer();
}
So while the above examples have been focusing on dictation and interaction with UI elements, this next
example will focus on the ability to listen for and interpret specific commands only. This also means that
dictation will be ignored completely, even though text input fields have focus.
For this purpose, we will use the SpeechRecognitionEngine class instead of the SpeechRecognizer
class. A huge difference between the two is that the SpeechRecognitionEngine class doesn't require the
Windows speech recognition to be running and won't take you through the voice recognition guide. Instead,
it will use basic voice recognition and listen only for grammar which you feed into the class.
In the next example, we'll feed a set of commands into the recognition engine. The idea is that it should
listen for two words: A command/property and a value, which in this case will be used to change the color,
size and weight of the text in a Label control, solely based on your voice commands. Before I show you the
entire code sample, I want to focus on the way we add the commands to the engine. Here's the code:
speechRecognizer.LoadGrammar(new Grammar(grammarBuilder));
We use a GrammarBuilder to build a set of grammar rules which we can load into the
SpeechRecognitionEngine. It has several append methods, with the simplest one being Append(). This
method takes a list of choices. We create a Choices instance, with the first part of the instruction - the
command/property which we want to access. These choices are added to the builder with the Append()
method.
In the end, we load it into the SpeechRecognitionEngine instance by calling the LoadGrammer() method,
which takes a Grammar instance as parameter - in this case based on our GrammarBuilder instance.
So, with that explained, let's take a look at the entire example:
<Window x:Class
="WpfTutorialSamples.Audio_and_Video.SpeechRecognitionCommandsSample"
xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="SpeechRecognitionCommandsSample" Height="200" Width
="325"
Closing="Window_Closing">
<DockPanel>
<WrapPanel DockPanel.Dock="Bottom" HorizontalAlignment
="Center" Margin="0,10">
<ToggleButton Name="btnToggleListening" Click
="btnToggleListening_Click">Listen</ToggleButton>
</WrapPanel>
<Label Name="lblDemo" HorizontalAlignment="Center"
VerticalAlignment="Center" FontSize="48">Hello, world!</Label>
</DockPanel>
</Window>
using System;
using System.Globalization;
using System.Speech.Recognition;
using System.Windows;
using System.Windows.Media;
namespace WpfTutorialSamples.Audio_and_Video
{
public partial class SpeechRecognitionCommandsSample : Window
{
private SpeechRecognitionEngine speechRecognizer = new
public SpeechRecognitionCommandsSample()
{
InitializeComponent();
speechRecognizer.SpeechRecognized +=
speechRecognizer_SpeechRecognized;
speechRecognizer.LoadGrammar(new
Grammar(grammarBuilder));
speechRecognizer.SetInputToDefaultAudioDevice();
}
speechRecognizer.RecognizeAsync(RecognizeMode.Multiple);
else
speechRecognizer.RecognizeAsyncStop();
}
On the screenshot, you see the resulting application, after I've used the voice commands "weight bold" and
"color blue" - pretty cool, right?
Now, besides building the Grammar, the most interesting part is where we interpret the command. This is
done in the SpeechRecognized event, which we hook up to in the constructor. We use the fully recognized
text to update the demo label, to show the latest command, and then we use the Words property to dig
deeper into the actual command.
First off, we check that it has exactly two words - a command/property and a value. If that is the case, we
check the command part first, and for each possible command, we handle the value accordingly.
For the weight and color commands, we can convert the value into something the label can understand
automatically, using a converter, but for the sizes, we interpret the given values manually, since the values
I've chosen for this example can't be converted automatically. Please be aware that you should handle
exceptions in all cases, since a command like "weight blue" will try to assign the value blue to the
FontWeight, which will naturally result in an exception.
1.21.5.2. Summary
As you can hopefully see, speech recognition with WPF is both easy and very powerful - especially the last
example should give you a good idea just how powerful! With the ability to use dictation and/or specific
voice commands, you can really provide excellent means for alternative input in your applications.