WPF Controls
The heart of any Windows Presentation Foundation application is its set of control types that populate a
user interface. As you would expect, WPF provides numerous controls to deal with textual data, user input,
lists, and selections, as well as UI elements to represent menu systems, status bars, and toolbars.
In this chapter, you will begin by reviewing the overall control programming paradigm and the WPF content
model. Next, you will examine the details of several useful WPF controls and the role of control commands.
Be aware that some of the more exotic controls such as the document controls will be examined in separate
chapters.
A Survey of WPF Controls
Like any GUI framework, WPF ships with a large number of intrinsic controls. Many of these controls will
be very familiar (Button, TextBox, Label), while others may be new (Expander and
FlowDocumentReader). While the WPF controls are independent from Windows Forms controls, they do
share some of the same property and event names.
Recall that a majority of WPF controls are defined within the System.Windows.Controls namespace.
PresentationFramework.dll is the assembly containing this namespace.
The following table documents the core WPF controls grouped by related functionality. Consult the .NET 3.5
Framework SDK documentation for full details.
Beyond these core control types, WPF defines additional controls:
• Advanced document processing (DocumentViewer, FlowDocumentReader, and more).
• Support for Ink API (useful for tablet PC development).
• A select number of canned dialog boxes (PasswordBox, PrintDialog).
If you are coming to WPF from a Windows Forms background, you may notice that the current offering of
intrinsic controls is somewhat less than that of Windows Forms. For example, WPF does not have a ‘spin
button’ control or exotic data grid controls. The good news is that many of these missing controls can be
expressed in XAML quite quickly (for example, a ‘spin control’) and can even be modeled as a user control
for reuse between projects.
Also, the PresentationFramework.dll assembly defines a handful of common dialogs within the Microsoft.
Win32 namespace. These file-centric dialog types make use of P/Invoke operations to call the Win32 APIs.
Reviewing the WPF Control Programming Model
Over the course of many years, developers have been conditioned to see controls as fairly fixed and
predictable entities. For example, Label widgets always have textual content and seldom have a visible
border, although they could. Buttons have textual content and may on occasion have an embedded image.
When a project demanded that a ‘standard’ widget (such as a Button) needed to be customized such as a
Button control rendered as a circular image, developers were often forced to build a customized control
through code.
WPF radically changes the way developers look at controls. Not only do developers have the option to
express a control’s look and feel through markup, but many WPF controls have been designed to contain any
sort of content. Any descendant of ContentControl can participate in this new model.
Recall from Chapter 1 that a ContentControl can only have a single item set as content. When you need to
assign complex content to a ContentControl, you will wrap each UI element into one of the panel types.
The panel will contain all the nested UI elements. The panel then becomes the ‘single piece of context’.
Consider the following customized Button type:
• Notice the button’s content is a <StackPanel>, which defines four sub-elements, one of which is
yet another <StackPanel>.
• You will examine the panel types later in this chapter. However, for the time being just know that a
<StackPanel> will align sub-elements vertically by default.
• Also note that the second <StackPanel>’s sub-elements are <Expander> controls, which will also
be examined later in this chapter.
<!-- A custom button with built-in selections. -->
<Button Name="btnPurchaseOptions" Height = "100" Width = "300">
<!-- This is the button’s single piece of content. -->
<StackPanel>
<Label Name = "lblInstructions" Foreground = "DarkGreen"
Content = "Select Your Options and Press to Commit"/>
<StackPanel Orientation = "Horizontal">
<Expander Name = "colorExpander" Header = "Color">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "MakeExpander" Header = "Make">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "paymentExpander" Header = "Payment Plan">
<!-- Assume items are placed here... -->
</Expander>
</StackPanel>
</StackPanel>
</Button>
By way of a simple compare and contrast, consider how this same control would be built using Windows
Forms. Under this API, you could achieve this control only by building a custom Button-derived type that
manually handled the rendering of the graphical content, updated the internal controls collection, overrode
various event handlers, and so forth. The only compelling reason to build a custom WPF control is if you
need a widget that supports custom behaviors (events, overriding of virtual methods, and so on) or must
support custom support design-time configuration. If you are only concerned with a customized rendering,
XAML fits the bill in the vast majority of cases.
It is always important to remember that ContentControl-derived types can only have a single piece of
content. Recall that content can be set explicitly with the Content property in the opening element of a
XAML definition. However, this will only work if the value is a simple string. To set the content implicitly,
use property-element syntax. This will be necessary when your content is more complex than a string literal.
<Button Name="btnPurchaseOptions" Height = "100" Width = "300">
<Button.Content>
<StackPanel>
<Label Name = "lblInstructions" Foreground = "DarkGreen"
Content = "Select Your Options and Press to Commit"/>
<StackPanel Orientation = "Horizontal">
<Expander Name = "colorExpander" Header = "Color">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "MakeExpander" Header = "Make">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "paymentExpander" Header = "Payment Plan">
<!-- Assume items are placed here... -->
</Expander>
</StackPanel>
</StackPanel>
</Button.Content>
</Button>
Recall that any control defined in XAML with a Name attribute can then be accessed in a related code file.
For example, you could change properties on the previous button as follows, given that you assigned a Name
value of btnPurchaseOptions.
// C# code (VB code would be similar).
public partial class MainWindow : System.Windows.Window
{
public MainWindow()
{
InitializeComponent();
btnPurchaseOptions.Height = 400;
}
}
This is possible because controls that are given a Name attribute in the XAML definition result in a member
variable in the autogenerated *.g.cs / *.g.vb file. For example, the previous XAML results in the following C#
code (VB code would be similar). Notice that the <StackPanel> types are not listed as member variables, as
you have not set a Name property to them.
// C# code (VB code would be similar).
public partial class MainWindow : System.Windows.Window,
System.Windows.Markup.IComponentConnector
{
// Member variables defined based on the XAML markup.
internal System.Windows.Controls.Button btnPurchaseOptions;
internal System.Windows.Controls.Label lblInstructions;
internal System.Windows.Controls.Expander colorExpander;
internal System.Windows.Controls.Expander MakeExpander;
internal System.Windows.Controls.Expander paymentExpander;
...
}
The heart of any Windows Presentation Foundation application is its set of control types that populate a
user interface. As you would expect, WPF provides numerous controls to deal with textual data, user input,
lists, and selections, as well as UI elements to represent menu systems, status bars, and toolbars.
In this chapter, you will begin by reviewing the overall control programming paradigm and the WPF content
model. Next, you will examine the details of several useful WPF controls and the role of control commands.
Be aware that some of the more exotic controls such as the document controls will be examined in separate
chapters.
A Survey of WPF Controls
Like any GUI framework, WPF ships with a large number of intrinsic controls. Many of these controls will
be very familiar (Button, TextBox, Label), while others may be new (Expander and
FlowDocumentReader). While the WPF controls are independent from Windows Forms controls, they do
share some of the same property and event names.
Recall that a majority of WPF controls are defined within the System.Windows.Controls namespace.
PresentationFramework.dll is the assembly containing this namespace.
The following table documents the core WPF controls grouped by related functionality. Consult the .NET 3.5
Framework SDK documentation for full details.
Beyond these core control types, WPF defines additional controls:
• Advanced document processing (DocumentViewer, FlowDocumentReader, and more).
• Support for Ink API (useful for tablet PC development).
• A select number of canned dialog boxes (PasswordBox, PrintDialog).
If you are coming to WPF from a Windows Forms background, you may notice that the current offering of
intrinsic controls is somewhat less than that of Windows Forms. For example, WPF does not have a ‘spin
button’ control or exotic data grid controls. The good news is that many of these missing controls can be
expressed in XAML quite quickly (for example, a ‘spin control’) and can even be modeled as a user control
for reuse between projects.
Also, the PresentationFramework.dll assembly defines a handful of common dialogs within the Microsoft.
Win32 namespace. These file-centric dialog types make use of P/Invoke operations to call the Win32 APIs.
Reviewing the WPF Control Programming Model
Over the course of many years, developers have been conditioned to see controls as fairly fixed and
predictable entities. For example, Label widgets always have textual content and seldom have a visible
border, although they could. Buttons have textual content and may on occasion have an embedded image.
When a project demanded that a ‘standard’ widget (such as a Button) needed to be customized such as a
Button control rendered as a circular image, developers were often forced to build a customized control
through code.
WPF radically changes the way developers look at controls. Not only do developers have the option to
express a control’s look and feel through markup, but many WPF controls have been designed to contain any
sort of content. Any descendant of ContentControl can participate in this new model.
Recall from Chapter 1 that a ContentControl can only have a single item set as content. When you need to
assign complex content to a ContentControl, you will wrap each UI element into one of the panel types.
The panel will contain all the nested UI elements. The panel then becomes the ‘single piece of context’.
Consider the following customized Button type:
• Notice the button’s content is a <StackPanel>, which defines four sub-elements, one of which is
yet another <StackPanel>.
• You will examine the panel types later in this chapter. However, for the time being just know that a
<StackPanel> will align sub-elements vertically by default.
• Also note that the second <StackPanel>’s sub-elements are <Expander> controls, which will also
be examined later in this chapter.
<!-- A custom button with built-in selections. -->
<Button Name="btnPurchaseOptions" Height = "100" Width = "300">
<!-- This is the button’s single piece of content. -->
<StackPanel>
<Label Name = "lblInstructions" Foreground = "DarkGreen"
Content = "Select Your Options and Press to Commit"/>
<StackPanel Orientation = "Horizontal">
<Expander Name = "colorExpander" Header = "Color">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "MakeExpander" Header = "Make">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "paymentExpander" Header = "Payment Plan">
<!-- Assume items are placed here... -->
</Expander>
</StackPanel>
</StackPanel>
</Button>
By way of a simple compare and contrast, consider how this same control would be built using Windows
Forms. Under this API, you could achieve this control only by building a custom Button-derived type that
manually handled the rendering of the graphical content, updated the internal controls collection, overrode
various event handlers, and so forth. The only compelling reason to build a custom WPF control is if you
need a widget that supports custom behaviors (events, overriding of virtual methods, and so on) or must
support custom support design-time configuration. If you are only concerned with a customized rendering,
XAML fits the bill in the vast majority of cases.
It is always important to remember that ContentControl-derived types can only have a single piece of
content. Recall that content can be set explicitly with the Content property in the opening element of a
XAML definition. However, this will only work if the value is a simple string. To set the content implicitly,
use property-element syntax. This will be necessary when your content is more complex than a string literal.
<Button Name="btnPurchaseOptions" Height = "100" Width = "300">
<Button.Content>
<StackPanel>
<Label Name = "lblInstructions" Foreground = "DarkGreen"
Content = "Select Your Options and Press to Commit"/>
<StackPanel Orientation = "Horizontal">
<Expander Name = "colorExpander" Header = "Color">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "MakeExpander" Header = "Make">
<!-- Assume items are placed here... -->
</Expander>
<Expander Name = "paymentExpander" Header = "Payment Plan">
<!-- Assume items are placed here... -->
</Expander>
</StackPanel>
</StackPanel>
</Button.Content>
</Button>
Recall that any control defined in XAML with a Name attribute can then be accessed in a related code file.
For example, you could change properties on the previous button as follows, given that you assigned a Name
value of btnPurchaseOptions.
// C# code (VB code would be similar).
public partial class MainWindow : System.Windows.Window
{
public MainWindow()
{
InitializeComponent();
btnPurchaseOptions.Height = 400;
}
}
This is possible because controls that are given a Name attribute in the XAML definition result in a member
variable in the autogenerated *.g.cs / *.g.vb file. For example, the previous XAML results in the following C#
code (VB code would be similar). Notice that the <StackPanel> types are not listed as member variables, as
you have not set a Name property to them.
// C# code (VB code would be similar).
public partial class MainWindow : System.Windows.Window,
System.Windows.Markup.IComponentConnector
{
// Member variables defined based on the XAML markup.
internal System.Windows.Controls.Button btnPurchaseOptions;
internal System.Windows.Controls.Label lblInstructions;
internal System.Windows.Controls.Expander colorExpander;
internal System.Windows.Controls.Expander MakeExpander;
internal System.Windows.Controls.Expander paymentExpander;
...
}
WPF Controls
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
|
Services