#19 – The System.Windows Namespace

Most user-interface related classes that a WPF application will use are located in the System.Windows namespace or one of its subordinate namespaces.

Some of the classes present in System.Windows :

  • Application – Encapsulated a WPF application
  • Clipboard – Transfer data to/from clipboard
  • ContentElement – Base class for contents elements, for flow-style presentation
  • DataObject – Transfering data
  • DataTemplate – Visual structure of a data object
  • DependencyObject – Object that participates in dependency property system
  • DependencyProperty – Properties that support data binding, inheritance, etc.
  • EventManager – Event-related utility methods
  • FrameworkElement – Extends UIElement & provides support for logical tree, et al
  • MessageBox – Displays a message box
  • ResourceDictionary – Dictionary that contains WPF resources
  • RoutedEvent – Routed event
  • Style – Sharing of properties/resources between instances
  • UIElement – Base class for graphical elements
  • UIElement3D – Base class for 3D elements
  • Window – Window in user interface

#18 – Silverlight and WPF Differences

Silverlight’s original name was WPF/E (WPF/Everywhere), underscoring the fact that Silverlight follows the same programming model as WPF and uses many of the same controls, but is based on a client library that is downloaded from the browser and targeted to run on a wider variety of platforms.

Core differences between WPF and Silverlight:

  • WPF runs only on Windows platforms
  • WPF expects .NET Framework to already be present on client
  • Silverlight can use a subset of all WPF controls
  • Silverlight uses a subset of the full .NET Framework and the CLR

Features present in WPF but not in Silverlight:

  • Flow document support
  • Dynamic resources
  • Merged dictionaries
  • Resetting a style to a new FrameworkElement
  • Style inheritance
  • Implicit styles with TargetType attribute
  • Triggers for Styles, ControlTemplates, DataTemplates.
  • Larger number of data binding features
  • Routed commands
  • Declaratively associate controls and commands
  • Inherit from UIElement
  • Custom markup extensions
  • Runtime-accessible visual and logical trees
  • Controls: AccessText, BulletChrome, ButtonChrome, ContextMenu, Decorator, DocumentPageView, DocumentViewer, GridViewColumnHeader, GridViewRowPresenter, GroupBox, GroupItem, InkCanvas, Menu, MenuItem, PageContent, Ribbon, Separator, StatusBar, TickBar, ToolBar, Track, UniformGrid,

Features present in Silverlight but not in WPF:

  • Deep Zoom
  • Controls: AutoCompleteBox, DataPager, DescriptionViewer, HyperlinkButton, MultiScaleImage, NumericUpDown, ValidationSummary

#17 – WPF Release History

Here’s the history of the various versions of WPF, along with the corresponding version of Visual Studio that supported it.  Since WPF is part of the .NET Framework, it is numbered based on the .NET Framework releases.  (E.g. WPF 3.5 refers to WPF release with .NET Framework 3.5).

  • .NET Framework 3.0 – Nov, 2006
    • 1st release of WPF
    • CLR version 2.0
    • Visual Studio 2005 SP1
    • Incl w/Windows Vista
  • .NET Framework 3.5 – Nov, 2007
    • Various improvements to WPF
    • CLR version 2.0 SP1
    • Visual Studio 2008
    • Incl w/Windows 7
  • .NET Framework 3.5 SP1 – Aug, 2008
    • Performance improvements (et al) to WPF
    • CLR version 2.0 SP2
    • Visual Studio 2008 SP1
  • .NET Framework 4.0 – Apr, 2010
    • Various improvements to WPF
    • CLR version 4.0
    • Visual Studio 2010
  • .NET Framework 4.5 – Aug, 2012
    • Various improvements to WPF
    • CLR version 4.5
    • Visual Studio 2012
    • Incl w/Windows 8

#16 – Use Direct3D For Hard-Core 3D Applications

Although WPF supports drawing 3D objects, Direct3D should still be used where an application needs 3D features not provided by WPF, or needs maximum performance in drawing 3D objects.

WPF 4.0 is based on DirectX 9, so it does not support Direct3D 10 or Direct3D 11.

#15 – WPF vs. Silverlight and ASP.NET

WPF, Silverlight and ASP.NET are Microsoft’s three main application development platforms.

  • WPF
    • For developing Windows applications
    • Thick client user interface, with most rich set of user controls and Windows-specific features
    • Platforms–runs only on Windows, in or out of browser
    • Requires full .NET Framework installed on client
  • Silverlight
    • For developing web applications that can also run out of browser
    • Thin client, with richer UI controls that are closer to traditional thick client controls
    • Platforms
      • Runs as browser plug-in in most browsers
      • Silverlight client software runs on Windows, Mac OS X, Windows Phone 7
      • Moonlight version of Silverlight allows running on Linux
    • Requires Silverlight framework installed on client (when page is first loaded)
    • For developing web applications
    • Thin client, with fairly generic web-based controls
    • Platforms–runs on server, so client is delivered as standard HTML on any platform–including browsers on mobile devices
    • Requires nothing to be installed on client

#14 – Page-Based Navigation

WPF applications can be structured as a collection of pages, with built-in navigation between pages.  This is different from the more traditional (Win Forms) document-based model, where the application displays a main window and dialogs that pop up.

To create a page-based application, you use a Page object as the top-level container in your application, instead of Window.

<Page x:Class="WpfApplication7.Page1"
      mc:Ignorable="d"  d:DesignHeight="300" d:DesignWidth="300"
        <Label Content="This is a page, not a window." Height="28" HorizontalAlignment="Left" Margin="52,75,0,0" Name="label1" VerticalAlignment="Top" />

To make this page the main object loaded when the application starts, set the StartupUri attribute of your main Application:

<Application x:Class="WpfApplication7.App"

Notice that we now get a main window with navigation controls at the top.

#13 – Benefits of Markup

Using a Markup + Code-Behind model for application development has a number of benefits, as opposed to defining everything in code.

Benefits of using Markup/XAML:

  • Can change look and feel of the application without changing the behavior
    • Can change look/feel by changing the XAML
  • Designers can work on appearance (XAML) at the same time that developers work on behavior (code)
  • Easier for design tools to render the application
    • Tool can just interpret XAML, rather than having to execute code that creates controls
    • Means  that tools other than Visual Studio (e.g. Blend) can be used to work on just the user interface
  • XAML can be generated programmatically by design tool

#12 – Markup and Code Behind

WPF applications are made up of markup (XAML) and code-behind (managed code).  The markup defines the layout and appearance of the application, whereas the code-behind defines the behavior.

WPF markup is written using XAML, a declarative markup language based on XML.  The XAML lists the controls that make up the application, how they are related, and how they appear.

        <Button Content="Save" Height="23" Name="btnSave" Width="75" Click="btnSave_Click" />
        <Button Content="Load" Height="23" Name="btnLoad" Width="75" Click="btnLoad_Click" />

The code-behind is the part of your application that exists as managed code (e.g. C#) and describes the behavior of the application at runtime.

private void btnSave_Click(object sender, RoutedEventArgs e)
    // Do actual work of saving file here

#11 – Commands

WPF provides support for commands, where a command is an object that performs a particular task independent from the GUI element that initiated the task.  The main purpose of commands is to move code common to multiple controls into a central location, out of the event handlers for the individual controls.  This allows multiple controls to invoke the same command logic.

You create a command by binding a command object to your code.

WPF includes a library of pre-created commands for common tasks like Copy, Cut and Paste.  These command objects are merely placeholders–you still have to write the code that does the actual work for each command.

Here’s an example of a Button being bound through a built-in command to custom code.

 <Button Content="New" Command="ApplicationCommands.New"/>
 // Create binding--which binds the command to your code
 CommandBinding binding = new CommandBinding(ApplicationCommands.New);
 binding.Executed += new ExecutedRoutedEventHandler(CommandNew_Executed);

#10 – Control Templates

Similar to styles in WPF, but different, are templates.  Templates allow you to replace all aspects of a UI control’s appearance without changing its behavior.

Every control in WPF has a default template that completely specifies its appearance.  You can replace the default template with a template that you’ve authored, to change the appearance of the control.

You change a control’s template by changing its Template property.  Here’s an example where we create a new button template that gives the button a thick blue border.

    <ControlTemplate x:Key="Crazy" TargetType="Button">
        <Border BorderBrush="Blue" Background="White" BorderThickness="3">
<Grid Height="auto" Width="503">
    <StackPanel Height="100" HorizontalAlignment="Left" Margin="85,139,0,0" Name="stackPanel1"  >
        <Button Content="Crazy template" Template="{StaticResource Crazy}"  />
        <Button Content="Default template" />