WPF Layout Basics

WPF Layout Basics

WPF provides a set of panels—special-purpose user interface elements whose job is to

arrange the elements they contain. Each individual panel type offers a straightforward

and easily understood layout mechanism. As with all WPF elements, layout objects

can be composed in any number of different ways, so although each individual panel

type is fairly simple, the flexible way in which they can be combined makes for a very

powerful layout system. And you can even create your own layout element types

should the built-in ones not meet your needs.

Table describes the main panel types built into WPF.* Whichever panel you use,

the same basicrule always applies: an element’s position is always determined by the

containing panel. Most panels also manage the size of their children.

WPF StackPanel

StackPanel is a very simple panel that arranges its children in a row or a column. You

will not normally use StackPanel to lay out your whole user interface. It is most useful

for arranging small subsections. Example 3-1 shows how to build a simple search

user interface.

Figure 3-1 shows the results. As you can see, the UI elements have simply been

stacked vertically one after another. This example used the Margin property to space

the elements out a little. Most elements use a single number, indicating a uniform

margin all around. The Button uses a pair of numbers to specify different vertical and

Table 3-1. Main panel types

Panel type Usage

StackPanel Lays children out in a vertical or horizontal stack; extremely simple, useful for managing small-scale

aspects of layout.

WrapPanel Lays children out from left to right, moving onto a new line each time it fills the available width.

DockPanel Allocates an entire edge of the panel area to each child; useful for defining the rough layout of simple

applications at a coarse scale.

Grid Arranges children within a grid; useful for aligning items without resorting to fixed sizes and positions.

The most powerful of the built-in panels.

Canvas Performs no layout logic—puts children where you tell it to; allows you to take complete control of

the layout process.

UniformGrid Arranges children in a grid where every cell is the same size.

Example . StackPanel search layout

<StackPanel Background="#ECE9D8">

<TextBlock Margin="3">Look for:</TextBlock>

<ComboBox Margin="3"/>

<TextBlock Margin="3">Filtered by:</TextBlock>

<ComboBox Margin="3"/>

<Button Margin="3,5">Search</Button>

<CheckBox Margin="3">Search in titles only</CheckBox>

<CheckBox Margin="3">Match related words</CheckBox>

<CheckBox Margin="3">Search in previous results</CheckBox>

<CheckBox Margin="3">Highlight search hits (in topics)</CheckBox>

</StackPanel>

horizontal margins. This is one of several standard layout properties available on all

WPF elements, which are all described in the “Common Layout Properties” section,

There is one problem with this layout: the Search button is much wider than you

would normally expect a button to look. The default behavior of a vertical

StackPanel is to make all of the controls the same width as the panel. Likewise, a

horizontal StackPanel will make all of the controls the same height. For the ComboBox

controls, this is exactly what we want. For the TextBlock and CheckBox controls, it

doesn’t show that the controls have been stretched to be as wide as the panel,

because they look only as wide as their text makes them look. However, a Button’s

visuals always fill its entire logical width, which is why the button in Figure 3-1 is

unusually wide. (See the upcoming “Fixed Size Versus Size to Content” sidebar for

more details on how this process works.)

When an element has been given a fixed amount of space that is greater than

required by its content, the way in which the extra space gets used is determined by

the HorizontalAlignment and VerticalAlignment properties.

We can prevent the button from being stretched across the panel’s whole width by

setting its HorizontalAlignment property to Left:

<Button Margin="3,5" HorizontalAlignment="Left">Search</Button>

HorizontalAlignment determines an element’s horizontal position and width in situations

where the containing panel gives it more space than it needs. The default is

Stretch, meaning that if more space is available than the child requires, it will be

stretched to fill that space. The alternatives—Left, Right, and Center—do not

attempt to stretch the element; these determine where the element will be placed

within the excess space, allowing the element to use its natural width. Here we are

using Left, meaning that the control will have its preferred width, and will be aligned

to the left of the available space.

The preceding example used the default vertical orientation. StackPanel also supports

horizontal layout. Example  shows a StackPanel with its Orientation property set

to Horizontal.

Example  Horizontal StackPanel layout

<StackPanel Orientation="Horizontal">

<TextBlock>This is some text</TextBlock>

<Button>Button</Button>

<Button>Button (different one)</Button>

<CheckBox>Check it out</CheckBox>

<TextBlock>More text</TextBlock>

</StackPanel>

WPF WrapPanel

WrapPanel works just like a StackPanel until it runs out of space. If you provide a horizontal

WrapPanel with more children than will fit in the available width, it will

arrange its content in a way similar to how a word processor lays out words on a

line. It puts the children in a row from left to right until it runs out of space, at which

point it starts on the next line.

WrapPanel is very simple to use. Just as with a StackPanel, you add a sequence of children,

as shows.

<WrapPanel Background="Beige">

<Button>One</Button>

<Button>Two</Button>

<Button>Three</Button>

<Button>Four</Button>

<Button>Five</Button>

<Button>Six</Button>

<Button>Seven</Button>

<Button>Eight</Button>

</WrapPanel>

WrapPanel also offers an Orientation property. Setting this to Vertical will arrange

the children in a sequence of vertical stacks, a layout style very similar to Windows

Explorer’s “List” view.

WrapPanel and StackPanel really are useful only for small-scale layout. You will need

to use a more powerful panel to define the overall layout of your application, such as

DockPanel.

WPF DockPanel

DockPanel is useful for describing the overall layout of a simple user interface. You

can carve up the basic structure of your window using a DockPanel, and then use the

other panels to manage the details.

A DockPanel arranges each child element so that it fills a particular edge of the panel.

If multiple children are docked to the same edge, they simply stack up against that

edge in order. By default, the final child fills any remaining space not occupied by

controls docked to the panel’s edges.

Example  shows a simple DockPanel-based layout. Five buttons have been added

to illustrate each option. Notice that four of them have a DockPanel.Dock attribute

applied. This property is defined by DockPanel to allow elements inside a DockPanel

to specify their position. DockPanel.Dock is an attachedproperty (as described in the

upcoming sidebar, “Attached Properties and Layout”).

<DockPanel>

<Button DockPanel.Dock="Top">Top</Button>

<Button DockPanel.Dock="Bottom">Bottom</Button>

<Button DockPanel.Dock="Left">Left</Button>

<Button DockPanel.Dock="Right">Right</Button>

<Button>Fill</Button>

</DockPanel>

Elements never overlap in a DockPanel, so each successive child only gets to use space

not already used by the previous children. By default, the final child takes all of the

remaining space, but if you would prefer to leave a blank space in the middle, you

can set the LastChildFill attribute of the DockPanel to False. (It defaults to True.)

The final child will dock to the left by default, leaving the center empty.

WPF Application Deployment

WPF Application Deployment

For the purposes of demonstration, let’s build something vital for procrastinators the

world over: an application to generate excuses. The application was started with the

“Windows Application (WPF)” project template in Visual Studio 2005 and was

implemented with some very simple code. When you run it, it gives you an excuse

from its vast database.

Simple Publishing

For anyone to use this wonderful application, it must be published. The simplest

way to publish your WPF application is by right-clicking on the project in the Solution

Explorer and choosing the Publish option, which will bring up the first page of

the Publish Wizard. It asks you to choose where you’d like to deploy your application, including

to the disk, to a network share, to an FTP server, or to a web site. By default, the

Publish Wizard will assume you want to publish to the Publish subdirectory of your

project directory. Clicking the Next button.Because we’ve chosen to publish to something besides a web site, the Publish Wizard

wants to know how users will access your published application—in other

words, from a URL, from a UNC path, or from some optical media. (If you choose to

publish to a web site, the only way to access the application is from a URL, so it

won’t bother to ask.) We’d like to test web deployment, so we pick that option and

leave the default URL alone. Clicking Next.

For WPF applications, lets us choose whether we’d like this application to

be made available online (when the computer is able to connect to the application’s

URL) as well as offline (when the computer can’t connect to the URL), or whether

you’d like the application to be only available online. These two options correspond

to the ClickOnce terms locally installed and online only, respectively.

It reminds us what we get with a locally installed ClickOnce application (i.e.,

the application will appear in the Start menu and in the Add or Remove Programs

Control Panel). Clicking Finish causes Visual Studio to publish the application to the

filesystem, including a publish.htm file that you can use to test deployment. If you

happen to have an IIS application set up in the same folder to which Visual Studio

publishes, it will launch the publish.htm file for you, 

For simple needs, this is the complete experience for publishing a WPF ClickOnce

locally installed application.

WPF Application Events

WPF Application Events

You can best see the life cycle of a standard application in the set of events that it

exposes:*

• Startup

• Activated

• Deactivated

• DispatcherUnhandledException

• SessionEnding

• Exit

Startup event

The Application object’s Startup event is fired when the application’s Run method is

called, and it is a useful place to do application-wide initialization, including the

handling of command-line arguments, which are passed in the StartupEventArgs:

void App_Startup(object sender, StartupEventArgs e) {

for (int i = 0; i != e.Args.Length; ++i) {

// do something useful with each e.Args[i]

...

}

}

Activated and Deactivated events

The Activated event is called when one of the application’s top-level windows is activated

(e.g., via a mouse click or Alt-Tab). Deactivated is called when your application is

active and another application’s top-level window is activated. These events are handy

when you want to stop or start some interactive part of your application:

void App_Activated(object sender, EventArgs e) {

ResumeGame( );

}

void App_Deactivated(object sender, EventArgs e) {

PauseGame( );

}

DispatcherUnhandledException event

The application’s dispatcher is an object that routes events to the correct place, including

unhandled exceptions. In the event that you’d like to handle an exception otherwise

unhandled in your application—maybe to give the user a chance to save his current

document and exit—you can handle the DispatcherUnhandledException event:

Application Lifetime | 45

void App_DispatcherUnhandledException(

object sender, DispatcherUnhandledExceptionEventArgs e) {

string err = "Oops: " + e.Exception.Message);

MessageBox.Show(err, "Exception", MessageBoxButton.OK);

// Only useful if you've got some way of guaranteeing that

// your app can continue reliably in the face of an exception

// without leaving this AppDomain in an unreliable state...

//e.Handled = true; // stop exception from bringing down the app

}

The Exception property of the DispatcherUnhandledExceptionEventArgs event argument

is useful to communicate to your users what happened, whereas the Handled

property is useful to stop the exception from actually bringing down the application

(although this is a dangerous thing to do and can easily result in data loss).

SessionEnding event

The SessionEnding event is called when the Windows session itself is ending (e.g., in

the event of a shutdown, logoff, or restart):

void App_SessionEnding(object sender, SessionEndingCancelEventArgs e) {

if (MessageBox.Show(

e.ReasonSessionEnding.ToString( ),

"Session Ending",

MessageBoxButton.OKCancel) == MessageBoxResult.Cancel) {

e.Cancel = true; // stop the session from ending

}

}

The ReasonSessionEnding property of the SessionEndingCancelEventArgs event argument

is one value in the ReasonSessionEnding enumeration:

namespace System.Windows {

public enum ReasonSessionEnding {

Logoff = 0,

Shutdown = 1,

}

}

The Cancel property is useful if you’d like to stop the session from ending, although

this is considered rude, and more progressive versions of Windows (like Vista) may

not let you change its decision to end a session at all.

Exit event

The Exit event is called when the application is actually exiting, whether the last

window has gone away, the Application.Shutdown method is called, or the session is

ending. One of the overloads of the Shutdown method allows the programmer to pass

an integer exit code, which is ultimately exposed by the process for use by your favorite Win32 process examination APIs. By default, this value is zero, but you can

observe or override it in the handlers for this event:

void App_Exit(object sender, ExitEventArgs e) {

e.ApplicationExitCode = 452; // keep 'em guessing...

}

WPF Top-Level Windows

WPF Top-Level Windows

A top-level window is a window that is not contained within or owned by another

window (window ownership is discussed in more detail later). A WPF application’s

main window is the top-level window that is set in the MainWindow property of the

Application object. This property is set by default when the first instance of the

Window class is created and the Application.Current property is set. In other words,

by default, the main window is the top-level window that’s created first after the

application itself has been created. If you like, you can override this default by setting

the MainWindow property manually.

In addition to the main window, the Application class provides a list of top-level

windows from the Windows property. This is useful if you’d like to implement a Window

menu.

To implement the Window menu, we first start with a MenuItem element:

<!-- Window1.xaml -->

<Window ...>

<Grid>

<Grid.RowDefinitions>

<RowDefinition Height="auto" />

<RowDefinition />

<RowDefinition Height="auto" />

</Grid.RowDefinitions>

<Menu>

<MenuItem Header="Window" x:Name="windowMenu">

<MenuItem Header="dummy item" />

</MenuItem>

</Menu>

</Grid>

</Window>

MenuItem is a HeaderedItemControl (as described in Chapter 5), which means that it

has header content that we’ll use to hold the name of the menu item (“Window”),

and subcontent that we’ll use to hold the menu items for each top-level window.

Notice the use of a dummy subitem to start with. Without this dummy item, you

won’t be able to get notification that the user has asked to show the menu items

(whether via mouse or via keyboard).

To populate the Window menu, we’ll handle the menu item’s SubmenuOpened event:

public partial class Window1 : Window {

...

public Window1( ) {

InitializeComponent( );

windowMenu.SubmenuOpened += windowMenu_SubmenuOpened;

}

void windowMenu_SubmenuOpened(object sender, RoutedEventArgs e) {

windowMenu.Items.Clear( );

foreach (Window window in Application.Current.Windows) {

MenuItem item = new MenuItem( );

item.Header = window.Title;

item.Click += windowMenuItem_Click;

item.Tag= window;

item.IsChecked = window.IsActive;

windowMenu.Items.Add(item);

}

}

void windowMenuItem_Click(object sender, RoutedEventArgs e) {

Window window = (Window)((MenuItem)sender).Tag;

window.Activate( );

}

}

When the SubmenuOpened event is triggered, we use the Application object’s Windows

property to get a list of each top-level Window, creating a corresponding MenuItem for

each Window.

Application Shutdown Modes

Some applications work naturally with the idea of a single main window. For example,

many applications (drawing programs, IDEs, Notepad, etc.) have a single top-level window

that controls the lifetime of the application itself (i.e., when the main window goes

away, the application shuts down). On the other hand, some applications have multiple

top-level windows or some other kind of lifetime control that’s independent of a single

main window.* You can specify when your application shuts down by setting the application’s

ShutdownMode property to one of the values of the ShutdownMode enumeration:

namespace System.Windows {

public enum ShutdownMode {

OnLastWindowClose = 0, // default

OnMainWindowClose = 1,

OnExplicitShutdown = 2,

}

}

The OnMainWindowClose value is useful when you’ve got a single top-level window,

and the OnLastWindowClose value is useful for multiple top-level windows (and is the

default). In either of these cases, in addition to the automatic application shutdown

the ShutdownMode policy describes, an application can also be shut down manually by

calling the Application object’s Shutdown method. However, in the case of

OnExplicitShutdown, the only way to stop a WPF application is by calling Shutdown:

public partial class Window1 : System.Windows.Window {

...

void shutdownButton_Click(object sender, RoutedEventArgs e) {

Application.Current.Shutdown();

}

}

You can change the shutdown mode in code whenever you like, or you can set it in

the application definition XAML:

<Application

x:Class="AppWindowsSample.App"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

StartupUri="Window1.xaml"

ShutdownMode="OnExplicitShutdown" />

WPF Applications and Settings

WPF Application Lifetime

In the Windows sense, an “application” is an address space and at least one thread of

execution (a.k.a. a “process”). In the WPF sense, an application is a singleton object

that provides services for UI components and UI programmers in the creation and

execution of a WPF program. More specifically, in WPF, an application is an

instance of the Application class from the System.Windows namespace.

WPF Explicit Application Creation

Example . Creating an application explicitly

using System;

using System.Windows; // the home of the Application class

class Program {

[STAThread]

static void Main( ) {

Application app = new System.Windows.Application();

Window1 window = new Window1( );

window.Show( );

app.Run();

}

}

Here, we’re creating an application inside an STA thread,* creating a window and

showing it, and then running the application. While the application is running, WPF

processes Windows messages and routes events to WPF UI objects as necessary.

When the Run method returns, messages have stopped being routed and generally

don’t start again (unless you show a modal window after the Run method returns, but

that’s not something you’ll usually do). During its lifetime, the application provides

various services.

WPF Application Access

One of the services the Application class provides is access to the current instance.

Once an instance of the Application class is created,† it’s available via the Current

staticproperty of the Application class. For example, the code in Example 2-1 is

equivalent to the code in Example 

Here, in the process’s entry point, we’re creating an application, creating and showing

the main window, and then running the application. Creation of the Application

object fills the static Application.Current property. Access to the current application

is very handy in other parts of your program where you don’t create the application

or when you let WPF create the application for you itself.

* The “Single Threaded Apartment” (STA) was invented as part of the native Component Object Model

(COM) to govern the serialization of incoming COM calls. All Microsoft presentation frameworks, native or

managed, require that they be run on a thread initialized as an STA thread so that they can integrate with

one another and with COM services (e.g., drag-and-drop).

† WPF makes sure that, at most, one Application object is created per application domain. For a discussion

of .NET application domains, I recommend Essential .NET, by Don Box with Chris Sells (Addison-Wesley

Professional)

Example . Implicitly filling in the Application.Current property

using System;

using System.Windows;

class Program {

[STAThread]

static void Main( ) {

// Fills in Application.Current

Application app = new System.Windows.Application();

Window1 window = new Window1( );

window.Show( );

Application.Current.Run(); // same as app.Run( )

}

}

Implicit Application Creation

Because a Main method that creates and runs an application is pretty darn common,

WPF can provide the process’s entry point for you. WPF projects generally designate

one XAML file that defines the application. For example, if we had defined our

application in a XAML file with code behind, it would look like Example 2-3.

Notice that Example 2-3 is defining a custom application class in this code

(ImplicitAppSample.App) that derives from the Application class. In the OnStartup

override, we’re only creating a window and showing it, assuming WPF is going to

create the Main for us that creates the instance of the App class and calls the Run

method (which calls the OnStartup method). The way that WPF knows which XAML

file contains the definition of the Application class is that the Build Action is set to

ApplicationDefinition.

The ApplicationDefinition Build Action lets WPF know which class is our application

and hooks it up appropriately in a Main method it generates for us, which saves

us from writing several lines of boilerplate code.

Example  Declaring an application in XAML

<!-- App.xaml -->

<Application

x:Class="ImplicitAppSample.App"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" />

// App.xaml.cs

using System;

using System.Windows;

namespace ImplicitAppSample {

public partial class App : System.Windows.Application {

protected override void OnStartup(StartupEventArgs e) {

// let the base class have a crack

base.OnStartup(e);

// WPF itself is providing the Main that creates an

// Application and calls the Run method; all we have

// to do is create a window and show it

Window1 window = new Window1( );

window.Show( );

}

}

}

Where WPF applications Works

WPF Where and we 

WPF applications have a great deal of power, at which this chapter can only hint.
The base services of the application aren’t too surprising, but the support for pagebased
navigation and browser hosting certainly adds a new capability for Windows
applications, further enhanced with .NET 2.0 ClickOnce support.
Building your application is a matter of grouping controls in containers—either single
content containers, like windows or buttons, or multiple content containers that
provide layout capabilities, like the canvas and the grid.
When bringing your controls together, you’ll want to populate them with data that’s
synchronized with the in-memory home of the data, which is what data binding is
for, and keep them pretty, which is what styles are for. If you want to declare data or
styles in your XAML, you can do so using resources, which are just arbitrarily named
objects that aren’t used to render the WPF UI directly.
If no amount of data or style property settings makes you satisfied with the look of
your control, you can replace it completely with control templates, which can comprise
other controls or graphics primitives. In addition, you can apply graphics
operations, like rotating, scaling, or animation, to 2D or 3D graphics primitives or
controls in WPF’s integrated way. These elements can further be gathered into documents
for viewing or printing.

More recently, the Windows Presentation Foundation (WPF) happened. Initially it
felt like another way to create my windows, menus, dialogs, and child controls.
However, WPF shares a much deeper love for content than has yet been provided by
any other Windows programming framework.
To support content at the lowest levels, WPF merges controls, text, and graphics
into one programming model; all three are placed into the same element tree in the
same way. And although these primitives are built on top of DirectX to leverage the
3D hardware acceleration that is dormant when you’re not running the latest twitch
game, they’re also built into .NET, providing the same productivity boost to WPF
programmers that Windows Forms programmers enjoy.
To help you arrange the content, whether in fixed or flow layout, WPF provides container
elements that implement various layout algorithms in a way that is completely
independent of the content they’re holding.
To help you visualize the content, WPF provides data binding, control templates,
and animation. Data binding produces and synchronizes visual elements on the fly
based on your content. Control templates allow you to replace the complete look of
a control while maintaining its behavior. Animation brings your user interface control
to life, giving your users immediate feedback as they interact with it. These features
give you the power to produce data visualizations so far beyond the capabilities
of the data grid, the pinnacle most applications aspire to, that even Edward Tufte
would be proud.
Combine these features with ClickOnce for the deployment and update of your
WPF applications, both as standalone clients and as blended with your web site
inside the browser, and you’ve got the foundation of the next generation of Windows

applications.

How XAML Markup Extensions Works

XAML Markup Extensions

Before we take a look at the results of our data binding, let’s take a moment to discuss

XAML markup extensions, which is what you’re using when you set an attribute

to something inside of curly braces (e.g., Text="{Binding Path=Name}"). Markup

extensions add special processing to XAML attribute values. For example, this:

<TextBox Text="{Binding Path=Name}" />

is just a shortcut for this (which you’ll recognize as the property element syntax):

<TextBox.Text>

<Binding Path="Name" />

</TextBox.Text>

Data Templates

With the data binding markup syntax explained, let’s turn back to our example data

binding application, which so far doesn’t look quite like what we had in mind,It’s clear that the data is making its way into the application, because the currently

selected name and nickname are shown for editing. The problem is that, unlike the

TextBox controls, which were each given a specific field of the Nickname object to show,

the ListBox is expected to show the whole thing. Lacking special instructions, it’s calling

the ToString method of each object, which results in only the name of the type. To

show the data, we need to compose a data template.

Example . Using a data template

<ListBox

ItemsSource="{Binding}"

IsSynchronizedWithCurrentItem="True">

<ListBox.ItemTemplate>

<DataTemplate>

<TextBlock>

<TextBlock Text="{Binding Path=Name}" />:

<TextBlock Text="{Binding Path=Nick}" />

</TextBlock>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

A data template is a set of elements that should be inserted somewhere. In our case,

we are specifying a data template to be inserted for each listbox item by setting the

ItemTemplate property. In Example, we’ve composed a data template from a text block that flows together two other text blocks, each bound to a property on a

Nickname object separated by a colon, At this point, we’ve got a completely data-bound application. As data in the collection

or the individual objects changes, the UI will be updated, and vice versa. However,

there is a great deal more to say on this topic, including binding to XML and

relational data, master-detail binding, and hierarchical binding.

Dependency Properties

Although our data source Nickname object made its data available via standard .NET

properties, we need something special to support data binding on the target element.

Even though the TextContent property of the TextBlock element is exposed

with a standard property wrapper, in order for it to integrate with WPF services like

data binding, styling, and animation, it also needs to be a dependency property. A

dependency property provides several features not present in .NET properties,

including the ability to inherit its value from a container element, provide for objectindependent

storage (providing a potentially huge memory savings), and change

tracking.

Most of the time, you won’t have to worry about dependency properties versus .NET

properties.

Resources

Resources are named chunks of data defined separately from code and bundled with

your application or component. .NET provides a great deal of support for resources,

a bit of which we already used when we referenced tom.png from our XAML button

earlier in this chapter. WPF also provides special support for resources scoped to elements

defined in the tree.

As an example, let’s declare some default instances of our custom Nickname objects in

XAML 

Notice the Window.Resources, which is property element syntax to set the Resources

property of the Window1 class. Here we can add as many named objects as we like,

with the name coming from the Key attribute and the object coming from the XAML

elements (remember that a XAML element is just a mapping to .NET class names).

In this example, we’re creating a Nicknames collection named names to hold three

Nickname objects, each constructed with the default constructor, and then setting

each of the Name and Nick properties.

Also notice the use of the StaticResource markup extension to reference the names

resource as the collection to use for data binding. With this XAML in place, our window

construction reduces to the code shown in Example 

Example . Declaring objects in XAML

<!-- Window1.xaml -->

<Window ... xmlns:local="clr-namespace:DataBindingDemo" />

<Window.Resources>

<local:Nicknames x:Key="names">

<local:Nickname Name="Don" Nick="Naked" />

<local:Nickname Name="Martin" Nick="Gudge" />

<local:Nickname Name="Tim" Nick="Stinky" />

</local:Nicknames>

</Window.Resources>

<DockPanel DataContext="{StaticResource names}">

<TextBlock DockPanel.Dock="Top" Orientation="Horizontal">

<TextBlock VerticalAlignment="Center">Name: </TextBlock>

<TextBox Text="{Binding Path=Name}" />

<TextBlock VerticalAlignment="Center">Nick: </TextBlock>

<TextBox Text="{Binding Path=Nick}" />

</TextBlock>

...

</DockPanel>

</Window>

Example . Finding a resource in code

public partial class Window1 : Window {

Nicknames names;

public Window1( ) {

InitializeComponent( );

this.addButton.Click += addButton_Click;

// get names collection from resources

this.names = (Nicknames)this.FindResource("names");

// no need to make data available for binding here

//dockPanel.DataContext = this.names;

}

void addButton_Click(object sender, RoutedEventArgs e) {

this.names.Add(new Nickname( ));

}

}

Now instead of creating the collection of names, we can pull it from the resources 

with the FindResource method. Just because this collection was created in XAML 

doesn’t mean that we need to treat it any differently than we treated it before, which 

is why the Add button event handler is the exact same code. Also, there’s no need to 

set the data context on the dock panel because that property was set in the XAML. 

For the full scoop on resources, including resource scoping and lookup, static and 

dynamic binding to resources, and using resources for theming and skinning,