Pete Brown's Blog (POKE 53280,0) for tag Tutorial-General-WPF

Threading Considerations for Binding and Change Notification in Silverlight 5

Pete Brown — Tue, 10 Jan 2012 16:48:00 GMT

A reader of my Silverlight 5 book recently reached out to me about threading and why I create some objects on the UI thread in the examples. We discussed some of the reasons, but I felt this would be a good topic to share with everyone. In fact, this is one area where it would have been fun to go into great detail in my book, but there simply wasn't the space. Threading and cross-thread exceptions can be a bit of a mystery to new Silverlight and WPF developers.

Background

The user interface in Silverlight runs on a thread commonly known as the UI Thread. Any code you create in the code-behind, and any code it calls all the way down the chain, unless it explicitly creates another thread, runs on this same UI thread. It's not at all uncommon to see Silverlight and WPF applications which never explicitly create a second thread, but do make calls to other services which create background threads for processing.

There are many other examples, but networking is one place where the Silverlight .NET Framework explicitly creates (or uses) different threads. Not all calls return on the UI thread.

Threads other than the UI thread are not allowed to access or manipulate UI objects. If they attempt to do so, the runtime throws an Invalid Cross-Thread Access exception. It looks like this:

But wait! I wasn't accessing any UI objects from my code. What gives?

It's not always obvious that you're interacting with UI objects on the UI thread, though. Here's the stack trace from this particular exception:

{System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --->

  System.UnauthorizedAccessException: Invalid cross-thread access.

   at MS.Internal.XcpImports.CheckThread()

   at MS.Internal.XcpImports.GetValue(IManagedPeerBase managedPeer, DependencyProperty property)

   at System.Windows.DependencyObject.GetOldValue(DependencyProperty property, EffectiveValueEntry& oldEntry)

   at System.Windows.DependencyObject.UpdateEffectiveValue(DependencyProperty property, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, ValueOperation operation)

   at System.Windows.DependencyObject.RefreshExpression(DependencyProperty dp)

   at System.Windows.Data.BindingExpression.SendDataToTarget()

   at System.Windows.Data.BindingExpression.SourcePropertyChanged(PropertyPathListener sender, PropertyPathChangedEventArgs args)

   at System.Windows.PropertyPathListener.ReconnectPath()

   at System.Windows.Data.Debugging.BindingBreakPoint.<>c__DisplayClass4.b__3()

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)

   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)

   at System.Delegate.DynamicInvokeImpl(Object[] args)

   at System.Delegate.DynamicInvoke(Object[] args)

   at MainPagexaml.BindingOperation(Object BindingState, Int32 , Action )}

This stack trace was generated by trying to raise a PropertyChangedNotification when I manipulated a model object from a background thread. So, it was obvious that I was working with an object on the background thread, but it wasn't obvious that I'd get a cross-thread exception (well it was in this case, as I contrived the example). If you consider a larger application where you have division of ownership for different pieces, a client-side developer may simply work with your viewmodel, but not realize you're farming some work out to another thread.

I wrote a blog post back in 2010 ( Essential Silverlight and WPF Skills: The UI Thread, Dispatchers, Background Workers and Async Network Programming) explaining some of the ways to work with threads and dispatching. I didn't have SynchronizationContext in there at the time, but it's something I tend to use a lot these days.

Let's take a look at a few of the common scenarios and how it works with threading.

Common Scenarios

All of these scenarios make use of a simple Customer class with a single property:

namespace SilverlightThreadingExample.Model

{

    public class Customer : Observable

    {

        private string _firstName;

        public string FirstName

        {

            get { return _firstName; }

            set { _firstName = value; NotifyPropertyChanged("FirstName"); }

        }

    }

}

The customer is observable that is, it notifies any listeners when properties change. While not necessary, I encapsulated the observable code in this base class. You could, instead, put the implementation in a partial class if you wanted to make sure your model object's signature from your ORM or whatever remains the same as it was on the server.

using System.ComponentModel;



namespace SilverlightThreadingExample

{

    public class Observable : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;



        protected void NotifyPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

        }

    }

}

This is actually a pretty typical approach to handling INotifyPropertyChanged. There are even more robust versions out there which use lambdas and reflection to help avoid passing in strings, but they ultimately come down to raising the PropertyChanged event. Many of them also fail to work properly in cross-thread situations.

I expose the Customer class and a collection of customers from a ViewModel class.

namespace SilverlightThreadingExample.ViewModel

{

    public class CustomerEntryViewModel : Observable

    {

        private Customer _currentCustomer;

        public Customer CurrentCustomer

        {

            get { return _currentCustomer; }

            set { _currentCustomer = value; NotifyPropertyChanged("CurrentCustomer"); }

        }



        private ObservableCollection _customers = new ObservableCollection();

        public ObservableCollection Customers

        {

            get { return _customers; }

        }



        public void LoadCustomersOnSameThread()

        {

            LoadDummyData();

        }



        private void LoadDummyData()

        {

            _customers.Add(new Customer() { FirstName = "Pete" });

            _customers.Add(new Customer() { FirstName = "Jon" });

            _customers.Add(new Customer() { FirstName = "Tim" });

            _customers.Add(new Customer() { FirstName = "Scott" });

            _customers.Add(new Customer() { FirstName = "Andy" });

            _customers.Add(new Customer() { FirstName = "Blaine" });

            _customers.Add(new Customer() { FirstName = "Jesse" });

            _customers.Add(new Customer() { FirstName = "Rey" });



            _currentCustomer = _customers[0];

        }



    }

}

Finally, the UI is bound to those classes. The DataContext for the UI (which will be set in code-behind) is the ViewModel.


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

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

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

    mc:Ignorable="d"

    d:DesignHeight="400" d:DesignWidth="600">



    

        

            

                

                

            



            
                     Grid.Column="0" Margin="10"

                     ItemsSource="{Binding Customers}"

                     SelectedItem="{Binding CurrentCustomer, Mode=TwoWay}">

                

                    

                        

                    

                

            



            

                
                         DataContext="{Binding CurrentCustomer}"

                         Text="{Binding FirstName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

The code-behind looks like this

using System.Windows;

using System.Windows.Controls;

using SilverlightThreadingExample.ViewModel;

using System.Threading;

using SilverlightThreadingExample.Model;



namespace SilverlightThreadingExample

{

    public partial class MainPage : UserControl

    {

        CustomerEntryViewModel _vm;



        public MainPage()

        {

            InitializeComponent();



            CreateViewModelOnUIThread();

        }





        private void CreateViewModelOnUIThread()

        {

            _vm = new CustomerEntryViewModel();



            _vm.LoadCustomersOnSameThread();



            DataContext = _vm;

        }





        private void AddCustomer_Click(object sender, RoutedEventArgs e)

        {

        }





        private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

        {

        }





        private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

        {

        }





    }

}

The methods are named to keep the context clear in this example. I wouldn't expect you to name your VM instantiation/locator method "CreateViewModelOnUIThread", for example.

Now let's look at those scenarios.

Changing a property value from a background thread

Often in an application, you have a class which is used in UI binding (an entity/model object) but still need to modify a property from code. Sometimes, you need to do that from a background thread. For example, you make a network call to get an updated price for an item. You will get a cross-thread access error when the class raises change notification events from that property setter. If the class is truly POCO (Plan Old CLR Object) and doesn't do any change notification or other event raising, you'll be fine. If, however, change notification is involved, you'll get the cross-thread exception.

Assuming the same Customer and Observable classes defined above, and the same XAML UI, the following code in the code-behind will throw that exception.

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

        {

            _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

        });



    t.Start();

}

The exception doesn't happen when you set the property value; that's perfectly acceptable. It happens here, at the highlighted line:

protected void NotifyPropertyChanged(string propertyName)

{

    if (PropertyChanged != null)

        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

}

So, what are the options for working around this? Let's consider two common approaches.

Approach 1

The first approach is to do the whole property change from the UI thread. To do this, simply wrap the property set code with a call to the dispatcher. You can use either the Dispatcher object, or if you keep a copy of the SynchronizationContext around, use that.

Here's some example code which implements this. The code looks a bit silly because I'm forcing a background thread. However, pretend that the background thread is a given and you need to work from it (again, the callback from a network call or something.)

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

    {

        Deployment.Current.Dispatcher.BeginInvoke(() =>

            {

                _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

            });

    });



    t.Start();

}

This approach works well, but requires the calling code to handle all the dispatching. If you have a number of properties to change in different bits of code, it gets a bit cumbersome. Let's look at another approach.

Approach 2

The real problem is the property change notification, so the the second approach is to dispatch just the change notification to the UI thread.

You can put this code into the Observable base class in order to avoid repeating it throughout all your classes.

// Code-behind

// ----------------------------------------------





// this version throws an exception if the Observable base class isn't doing thread checking

private void ChangeNameFromSecondThread_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

        {

            _vm.CurrentCustomer.FirstName = "UpdatedFromSecondThread";

        });



    t.Start();

}





// Observable

// ----------------------------------------------





using System.ComponentModel;

using System.Windows;



namespace SilverlightThreadingExample

{

    public class Observable : INotifyPropertyChanged

    {

        public event PropertyChangedEventHandler PropertyChanged;



        protected void NotifyPropertyChanged(string propertyName)

        {

            if (PropertyChanged != null)

            {

                if (Deployment.Current.Dispatcher.CheckAccess())

                {

                    PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

                }

                else

                {

                    Deployment.Current.Dispatcher.BeginInvoke(() =>

                    {

                        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

                    });

                }

            }

        }

    }

}

Note how I first check to see if we have access to the UI thread using the CheckAccess call. If we do, there's no reason to incur the overhead and delay of a dispatcher call. However, if we are running on the background thread, then the call is dispatched to the UI thread. In either case, we avoid the errors cause by cross-thread property change notification.

Next up: Collections

Populating an ObservableCollection from a networking return call

A more robust Observable base class like this won't help with collection change notification (WPF 4.5 has a great solution for that using BindingOperations.EnableCollectionSynchronization, but unfortunately Silverlight does not).

Most applications make networking calls to get information from some resource on an intranet or out on the web. In Silverlight (and WPF), it's common practice to populate an ObservableCollection with the results from those calls. The ObservableCollection class is nice because it implements INotifyCollectionChanged and raises an event whenever items are added to or deleted from the collection, or when the collection is cleared. It's this notification that enables the various items controls and grids in the UI to stay in sync with the items in the collection.

This version is very similar to what we saw with individual properties earlier. That's because, it's really the same problem: we're trying to notify the binding system across threads.

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    Thread t = new Thread((o) =>

    {

        var cust = new Customer() { FirstName = "AddedFromSecondThread" };

        _vm.Customers.Add(cust);

    });



    t.Start();

}

Note that the problem exists regardless of where you actually create the customer. For example, this code will also fail:

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    var cust = new Customer() { FirstName = "AddedFromSecondThread" };



    Thread t = new Thread((o) =>

    {

        _vm.Customers.Add(cust);

    });



    t.Start();

}

The reason is, again, it's not the object access that is causing the cross-thread exception, it's the collection changed notification that's full of hate here.

So, how do you get around this? Unless you want to create your own ObservableCollection type class for Silverlight, you'll need to dispatch all collection add calls. Luckily, you'll typically have fewer of these scattered throughout the application, so it's not quite so onerous.

The code to implement this is just another easy call to the dispatcher (or SynchronizationContext, if you prefer).

private void AddCustomerSecond_Click(object sender, RoutedEventArgs e)

{

    // you can create customer on any thread

    var cust = new Customer() { FirstName = "AddedFromSecondThread" };



    Thread t = new Thread((o) =>

        {



            // dispatch to UI thread to add it to the collection. You can't

            // access the observable collection x-thread

            Deployment.Current.Dispatcher.BeginInvoke(() =>

                {

                    _vm.Customers.Add(cust);

                });

        });



    t.Start();

}

If you're going to run from an unknown state, be sure to call CheckAccess to see if you really need to do the dispatching. In this case, I know I'm always going to be on a background thread, so I don't bother.

Summary

The intent here was to show a few of the common threading pitfalls in Silverlight (and WPF) applications, specifically in the context of change notification. In most code, it's easy to tell when you're accessing objects cross-thread, but change notification is a somewhat behind the scenes operation, so it's not always obvious.

For property change notification, the solutions were:

Dispatch the entire property change operation to the UI thread
Update the NotifyPropertyChanged code to check to see which thread it's running on, and then dispatch the event as appropriate

Either way works, but I prefer the update to the NotifyPropertyChanged method.

For collection change notifications in Silverlight, the solutions are:

Create (or find) an implementation of ObservableCollection which does the cross-thread checking. The reason this isn't built-in is change notification happens often, and dispatching each and every change notification can be a real performance drain. That's also why WPF has a separate and optimized solution. You'd need to enable batching to avoid the overhead of hundreds of dispatch calls.
Dispatch the entire collection update when you're running on a background thread.

In contrast to the property change notifications, for collection change, I prefer to dispatch the entire call. If you're adding 1 object or 100, you'll still get only one dispatch call, so performance is better.

The Task Parallel Library in WPF, and the subset of it in Silverlight also offer some alternative approaches to handling cross-thread work. Similarly, the async and await keywords in .NET 4.5 and Windows 8 XAML can also come into play. More on those in the future.

Creating a Custom Markup Extension in WPF (and soon, Silverlight)

Pete Brown — Wed, 09 Mar 2011 05:15:07 GMT

WPF currently, and Silverlight in v5, enables you to create your own custom markup extensions. Markup extensions are those little strings in XAML that are typically (but not always) enclosed in {curly braces} which, as the name implies, add new functionality to XAML. The most commonly used markup extensions are the {StaticResource}, {TemplateBinding}, and {Binding} extensions.

Creating your own markup extensions is a nice way to integrate your view of the world into the toolset. They're particularly popular with MVVM and similar toolkits.

This article is, in part, an excerpt from early work in Silverlight 5 in Action, the revised edition of Silverlight 4 in Action. SL5 in Action is due out by the end of 2011, and will have a MEAP (early access bits) around the time of the first public developer release of Silverlight 5.

Creating a Simple Markup Extension

There's not much ceremony to creating a markup extension. The amount of effort required is directly proportional to the complexity of what you're trying to do. For example:

public class HelloExtension : MarkupExtension

{

  public HelloExtension() { }



  public override object ProvideValue(

                  IServiceProvider serviceProvider)

  {

    return "Hello";

  }

}

As shown in this example, to create a markup extension, you need only inherit from MarkupExtension and override the ProvideValue method. The empty constructor is necessary for use in XAML, specifically when you include additional parameterized constructors.

When you use the markup extension, you must declare the namespace as explained in section 2.1.2 (of Silverlight 4/5 in Action), and use the class name in your XAML. For example, the following XAML uses the HelloExtension markup extension we just created.

Because we followed the convention of naming our markup extension with the suffix "Extension", we refer to it simply as "Hello" not "HelloExtension". The convention is helpful, but not required. When run, the result

One interesting thing is that markup extensions can be blown out using property element syntax. So, you could use the curly braces as shown above, or you could get the same effect by writing it this way:

This can be important for some scenarios where you need finer control over what you pass in, as we'll see later.

That was a super-simple example, but shows how little you need to do to create a markup extension. Next, we'll look at how to make an extension that takes in a parameter or two.

Creating a Markup Extension with Support for Parameters

Typically, markup extensions will be more complex and include the ability to accept parameters. As we previously saw, the built-in examples such as Binding, take in a number of discrete parameters which are used to provide key values as well as to alter their behavior.

This example shows how to create an interesting markup extension which will always return the maximum of two provided values.

public class MaxValueExtension : MarkupExtension

{

  public MaxValueExtension() { }



  public MaxValueExtension(object value1, object value2)

  {

    Value1 = value1;

    Value2 = value2;

  }



  [ConstructorArgument("value1")] 

  public object Value1 { get; set; }



  [ConstructorArgument("value2")] 

  public object Value2 { get; set; }



  public override object ProvideValue(

                         IServiceProvider serviceProvider)

  {

    if (Value1 is IComparable && Value2 is IComparable)

    {

      IComparable val1 = Value1 as IComparable;

      IComparable val2 = Value2 as IComparable;



      if (val1.CompareTo(val2) >= 0)

        return Value1.ToString(); 

      else

        return Value2.ToString(); 

    }

    else

    {

      return string.Empty;

    }

  }

}

Compared to the previous example, this adds a few new elements. First, we have a constructor accepting two parameters. Those two parameters are also provided as discrete properties. Note that the properties have been marked up so they map to the parameters - this is used by XAML serialization and, while not required, is a good practice.

Arguably, there's at least one cheat in this code: I coerce the final returned value to a string. That limits its usefulness for anything other than a Text or Content property. However, it keeps this example simple.

To use the markup extension, the syntax is similar. There's a subtle bug in this approach, however, which I'll explain after the example.

In this example, you'd expect the TextBlock to display 200, but it displays 25. This is because the values, in the absence of any other type cues, are treated as strings. One way to force them to be treated as numbers is to break the statement out using the property element syntax described earlier. The next example shows the verbose approach to using the markup extension


      xmlns:sys="clr-namespace:System;assembly=mscorlib">

  

    

      

        

          200

        

        

          25

This markup shows the expanded approach. While this is significantly longer than the previous example, it does provide complete control over the parameters. Note also that the MaxValue markup extension uses its full name MaxValueExtension when referencing its own parameters.

With the types correctly specified, it works as expected. Of course, you could build intelligence into your markup extension or use other ways of forcing the types. You could even create a markup extension that always returns an integer and use that as a parameter to your MaxValue extension.

Let's go the approach of adding some brains to our markup extension.

Creating a Markup Extension with Type Casting Support

So far, we've done nothing with the IServiceProvider parameter to the ProvideValue function. That object provides some interesting information about the target that this extension is going to populate. The IServiceProvider interface includes a GetService function which can return an IProvideValueTarget. Using that interface, you can access the target object and property, get property/type information from them, and set the property value directly.

In our case, we want to make sure that if we pass in two ints, but plan to use the result in a TextBlock, that the resulting int is converted to a string. If you leave the conversion out, you will get an error at runtime when you specify the types using, for example, this syntax (same approach as the earlier example):


        xmlns:sys="clr-namespace:System;assembly=mscorlib">

    

        

            

                

                    100

                

                

                    90

As mentioned previously, you normally get strings as parameters unless you break it out and get explicit with what you're passing in. Once you do that, you have to build conversion smarts into your markup extension. Here's the full markup extension with the type conversion logic built in.

using System;

using System.Windows.Markup;

using System.Windows;

using System.Reflection;



namespace CustomMarkupExtensions

{

    // totally optional. I have the return type here just so you know

    // it's possible. With a return type of object, you wouldn't normally

    // include the return type attribute

    [MarkupExtensionReturnType(typeof(object))]

    public class MaxValueExtension : MarkupExtension

    {

        public MaxValueExtension() { }



        public MaxValueExtension(object value1, object value2)

        {

            Value1 = value1;

            Value2 = value2;

        }



        [ConstructorArgument("value1")]

        public object Value1 { get; set; }



        [ConstructorArgument("value2")]

        public object Value2 { get; set; }



        private object GetMaxValue()

        {

            if (Value1 is IComparable && Value1 is IComparable)

            {

                if (((IComparable)Value1).CompareTo(Value2) >= 0)

                    return Value1;

                else

                    return Value2;

            }

            else

            {

                // use val1

                return Value1;

            }

        }



        public override object ProvideValue(IServiceProvider serviceProvider)

        {

            if (serviceProvider == null)

                return null;



            // get the target of the extension from the IServiceProvider interface

            IProvideValueTarget ipvt =

                (IProvideValueTarget)serviceProvider.GetService(typeof(IProvideValueTarget));

         

            DependencyObject targetObject = ipvt.TargetObject as DependencyObject;



            object val = GetMaxValue();



            if (ipvt.TargetProperty is DependencyProperty)

            {

                // target property is a DP

                DependencyProperty dp = ipvt.TargetProperty as DependencyProperty;



                if (val is IConvertible)

                {

                    val = Convert.ChangeType(val, dp.PropertyType);

                }

            }

            else

            {

                // target property is not a DP, it's PropertyInfo instead.

                PropertyInfo info = ipvt.TargetProperty as PropertyInfo;



                if (val is IConvertible)

                {

                    val = Convert.ChangeType(val, info.PropertyType);

                }

            }



            return val;

        }

    }

}

This example is more complex, but if you break down the code, there's nothing magical going on here. Inside ProvideValue, I check to see if we have a DependencyProperty or a regular property. Based on the type of property we're accessing, I get the PropertyType and then, if the type is convertible, call Convert.ChangeType to handle the type conversion.

MarkupExtensions can provide some interesting functionality to your XAML. Of course, you'll want to temper this with testability concerns (it's harder to test this than logic in your viewmodel), but it can get you out of some scrapes, and otherwise clean up nasty glue/utility code you may need to write in your code-behind.

This was written against and tested on WPF4. I haven't tested this on Silverlight 5, so if you're reading this in the Silverlight 5 timeframe, your mileage may vary.

Asynchronous Web and Network Calls on the Client in WPF (and Silverlight and .NET in general)

Pete Brown — Fri, 18 Feb 2011 00:43:01 GMT

An asynchronous network call is one in which you fire off a method and don't block the thread while waiting for it to return. This introduces some complexities since you have to somehow be notified of the success or failure of the call, and need to somehow retrieve the results.

Silverlight developers are used to making asynchronous network calls because that's all the stack has supported since first released. However, WPF developers can benefit from a little async code in their applications to help make things a bit more responsive.

Solution Setup

I created a solution into which I put a regular WPF Windows application and an empty ASP.NET Web application.

Services Project

Into the ASP.NET Web Application, I added a "Silverlight-enabled WCF Service". Why that template? It's a super simple approach to creating WCF services that act like regular old SOAP services. It keeps the example easy to follow.

The service is in a Services subfolder on the web project and is named CustomerService.svc. Here's the code:

using System;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

using System.ServiceModel.Activation;

using System.Collections.Generic;



namespace WebServicesSite.Services

{

    [ServiceContract(Namespace = "")]

    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

    public class CustomerService

    {

        [OperationContract]

        public IList GetCustomers()

        {

            List results = new List();



            results.Add(new Customer() { LastName = "Brown", FirstName = "Pete" });

            results.Add(new Customer() { LastName = "Stagner", FirstName = "Joe" });

            results.Add(new Customer() { LastName = "Liberty", FirstName = "Jesse" });

            results.Add(new Customer() { LastName = "Galloway", FirstName = "Jon" });



            return results;

        }



      

    }

}

In the same folder on the ASP.NET Service project, I added a class named "Customer":

namespace WebServicesSite.Services

{

    public class Customer

    {

        public string FirstName { get; set; }

        public string LastName { get; set; }

    }

}

Once you have the service set up, you'll want to fix the web project's port just to ensure that you don't hang the service and get stuck with a new port the next time you run. That results in your app not finding the service and can be hard to debug unless you know what you're looking for.

The actual port number isn't that important; I used the default. Just be sure to set to Specific port to lock in that port number. Silverlight developers: this isn't a bad idea when working on your own web services in your projects.

Next, add a service reference from your WPF project to the new service in the ASP.NET project (be sure to build the solution first). I named the namespace "Services"

Before clicking "OK", click the "Advanced…" button and select the option to generate the asynchronous client operations. In Silverlight, this is on by default as there's no other option. In WPF, however, async operations are less typical.

If you received an error downloading the metadata, you need to successfully build the web project first.

Next, we'll need to build some basic UI.

User Interface

I used the designer in Visual studio 2010 to create a dead simple user interface. (In Xaml, I changed Name to x:Name as is my habit), and added a simple item template to the ListBox. Here's the markup:


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

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

        Title="Async Service Example"

        Height="350"

        Width="525">

The first approach we'll look at is the simple event-based approach. So double-click that button and create an event handler we can use in the remaining examples.

The Event Approach

When it's possible to use the event approach, this is by far the easiest way to handle asynchronous calls, and is the approach used most often in Silverlight code as well.

private void CallService_Click(object sender, RoutedEventArgs e)

{

    var client = new Services.CustomerServiceClient();



    client.GetCustomersCompleted += (s, ev) =>

        {

            CustomerList.ItemsSource = ev.Result;

        };



    client.GetCustomersAsync();

}

To keep the code even tighter, I used an anonymous delegate and lambda expression to set up the event handler. You could also break it apart into a separate method, but I personally find that muddies the code.

The event approach is nice because you don't typically need to worry about threading and marshaling a result back to the UI thread; that's taken care of for you.

The next approach is a bit more flexible, but is also more complex.

The Callback Approach

Another common approach is the callback approach. I often think of this as the bare-bones method, as it is definitely a level or two lower than the event approach. However, you gain some additional flexibility in that there are no threading assumptions made, and you can pass around your own state objects.

private void CallService_Click(object sender, RoutedEventArgs e)

{

    // we'll need this to update the UI

    SynchronizationContext context = SynchronizationContext.Current;



    var client = new Services.CustomerServiceClient();



    // this can be anything: a custom class or whatever you need

    // to track state from the call to the response

    CustomerRequestState requestState = new CustomerRequestState();

    requestState.Client = client;

    requestState.Context = context;



    IAsyncResult asyncResult = client.BeginGetCustomers(

        new AsyncCallback(ResponseCallback), requestState);

}



private void ResponseCallback(IAsyncResult asyncResult)

{

    CustomerRequestState asyncState = asyncResult.AsyncState as CustomerRequestState;



    Customer[] customers = asyncState.Client.EndGetCustomers(asyncResult);



    // you can't just do this, as you'll get a cross-thread access error

    //CustomerList.ItemsSource = customers;



    // use SynchronizationContext and an anonymous delegate

    // to update the listbox in the UI

    asyncState.Context.Post((o) =>

        { CustomerList.ItemsSource = customers; }, null);



}

To make this work, we'll also need to create a state object to hold the bits we want to pass from the call to the response loading. I decided to track the calling WCF client (we'll need a reference to that), the synchronization context, and an arbitrary bit of data I don't actually use. Your own object can contain as little or as much as you need.

namespace WpfAsyncExample

{

    class CustomerRequestState

    {

        public string AnythingYouWant { get; set; }

        public CustomerServiceClient Client { get; set; }

        public SynchronizationContext Context { get; set; }

    }

}

Now, I mentioned that I am passing around a SynchronizationContext. That object allows us to make calls back on the original calling thread, in this case, the UI thread. We need to be able to marshal calls to that thread in order to update the user interface. If you try and update the UI from a non-UI thread, you'll get a cross-thread access exception.

Now, to keep things simple and understandable in the above code, I haven't done any error handling or proper disposal of objects. Make sure you do that in your production code.

The final approach we'll look at builds upon what we've seen so far, but makes it easier to do things like chain successive calls without all the cruft you'd normally use.

Using Reactive Extensions

The final example uses an additional library knows as "Reactive Extensions for .NET" or "Rx". This library does a ton of things to help handle asynchronous operations without making your code into an unintelligible bowl of calls and response callbacks.

First, get Reactive Extensions. You can either download it from the main site, or better yet, use NuGet to add it directly to your project. The NuGet approach will save you a ton of time. Learn how to use NuGet in your WPF projects here.

PM> install-package Rx-All

'Rx-Core (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-AsyncLinq (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-Interactive (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-Main (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-ClientProfile (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-ExtendedProfile (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

'Rx-Testing (≥ 1.0.2856.0)' not installed. Attempting to retrieve dependency from source...

Done

You are downloading Rx-Core from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-Core 1.0.2856.0'

You are downloading Rx-AsyncLinq from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-AsyncLinq 1.0.2856.0'

You are downloading Rx-Interactive from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-Interactive 1.0.2856.0'

You are downloading Rx-Main from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-Main 1.0.2856.0'

You are downloading Rx-ClientProfile from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-ClientProfile 1.0.2856.0'

You are downloading Rx-ExtendedProfile from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-ExtendedProfile 1.0.2856.0'

You are downloading Rx-Testing from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-Testing 1.0.2856.0'

You are downloading Rx-All from Microsoft Corporation, the license agreement to which is available at http://go.microsoft.com/fwlink/?LinkID=186234. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Rx-All 1.0.2856.0'

Successfully added 'Rx-Core 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-AsyncLinq 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-Interactive 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-Main 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-ClientProfile 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-ExtendedProfile 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-Testing 1.0.2856.0' to WpfAsyncExample

Successfully added 'Rx-All 1.0.2856.0' to WpfAsyncExample



PM>

While that added a bit more than we'll use in this example, you can control exactly what you get by only installing those packages. Rx-All was the easiest thing for me to do for this example. There are more than a few ways we can use Rx here, so I'm going to concentrate on just one: using the event approach.

private void CallService_Click(object sender, RoutedEventArgs e)

{

    // we'll need the UI thread just like last time

    SynchronizationContext context = SynchronizationContext.Current;



    var client = new Services.CustomerServiceClient();



    // Wait for the GetCustomersCompleted event to finish. When

    // it finishes, get the results from the event and

    // using the thread context from "context", set the

    // customer listbox item source to the result

    var o = Observable.FromEvent(

                                   client, "GetCustomersCompleted")

        .ObserveOn(context)

        .Select(result => result.EventArgs.Result)

        .Subscribe(s => CustomerList.ItemsSource = s);

          

    // kick it off

    client.GetCustomersAsync();

}

The code here initially looks as complex as the previous versions, or at least as complex as the event version. However, one subtle difference is that it has provided a nice way for us to chain additional dependent calls. For example, so you need to first call to get a customer ID, then make a separate call to get all the invoices for that customer. That could involve some pretty ugly call chaining in either the event approach or the callback approach. The Rx approach will allow you to more easily chain those calls together.

When you run the application, in all three approaches, you should see the results shown here. Of course, what I have presented is a simple example. In a real application, both the effort and the benefits are greater.

Why is this even Necessary?

Like many of the practices we follow, it's not strictly necessary. However, if you want to have a better user experience, using either a spawned thread or an async call for service calls can help keep your UI responsive.

Using async network calls also helps make your code and skills more compatible with Silverlight. All the code here is compatible with Silverlight.

Consider using async operations in your next desktop application.

NuGet for WPF and Silverlight Developers

Pete Brown — Thu, 10 Feb 2011 22:38:45 GMT

NuGet is package management system for .NET and Visual Studio. It allows people to create simple packages that install files into your projects, adds references etc. It makes it super simple to get working components and even scaffolding into your application without having to search your drive, manually find references, resolve dependencies etc.

NuGet is a Visual Studio extension that makes it easy to install and update open source libraries and tools in Visual Studio.

When you use NuGet to install a package, it copies the library files to your solution and automatically updates your project (add references, change config files, etc). If you remove a package, NuGet reverses whatever changes it made so that no clutter is left.

While NuGet is most popular with the ASP.NET crowd, it's growing in popularity with Silverlight and WPF developers as well. Recently, in response to a little prodding Scott Hanselman gave both me and Tim, Tim Heuer did the work to get the Silverlight Toolkit on NuGet. That's awesome :)

NuGet is a painless install that doesn't screw up other stuff. It's a simple Visual Studio extension. Let's try it out.

Step 1: Install NuGet

Go to nuget.org and click on the giant "Install NuGet" button

NuGet comes as a nice Visual Studio Extension installer (.vsix). Go ahead and open it and allow it to install into Visual Studio. It takes about 3 seconds on my SSD :)

Step 2: Find a Package

There are two main modes of operation for NuGet: the dialog approach and the command line approach. There's a great Getting Started tutorial on the NuGet codeplex site, so I'll only cover a subset of it here.

Let's see what's out there for WPF and Silverlight. We'll try the command-line approach. Under the tools menu, open the Library Package Manager (NuGet) Console

Once you see the Package Manager Console command prompt at the bottom of your screen, type "get-package -remote" to list of the available packages in the official NuGet Repository. In the current release, it may truncate the list if it's too long (that's being fixed today). In the mean time, let's try a little filter/search.

Type "get-package -filter wpf" to see ones with the word WPF in the ID or description. It returned this for me:

PM> get-package -remote -filter wpf



Id                                                                   Version                                                              Description                                                    

--                                                                   -------                                                              -----------                                                    

AvalonEdit                                                           4.0.0.7070                                                           AvalonEdit is the WPF-based text editor used in SharpDevelop 4.0...

AvalonEdit.Sample                                                    4.0.0.7070                                                           Sample code for AvalonEdit the WPF-based text editor used in Sha...

Catel.Windows                                                        0.9.2                                                                Catel.Windows library which includes the MVVM Framework for WPF ...

Catel.Windows                                                        1.0.0                                                                Catel.Windows library which includes the MVVM Framework for WPF ...

EF4Templates                                                         1.1.0.1                                                              EF4 Templates uses T4toolbox to generate Repositories, Unit of w...

MvvmLight                                                            3.0.0.29166                                                          The MVVM Light Toolkit is a set of components helping people to ...

MVVMT4                                                               1.0.0.0                                                              T4 Templates for generating view models, and views for WPF, Silv...

netfx-System.Windows.Input.DelegateCommand                           1.0.0.0                                                              An implementation of WPF ICommand that allows passing delegates/...

Observal                                                             1.0.0.0                                                              Observal is a library that helps you to manage complex, hierarch...

Prism                                                                4.0.0.0                                                              Prism helps you more easily design and build rich, flexible, and...

reactiveui                                                           2.0.0.2                                                              An MVVM library for WPF and Silverlight that is deeply integrate...

reactiveui-xaml                                                      2.0.0.2                                                              WPF and Silverlight specific extensions to ReactiveUI, formerly ...

reactivexaml                                                         1.4.0.0                                                              A MVVM library for WPF and Silverlight that is deeply integrated...

reactivexaml                                                         1.4.1.0                                                              A MVVM library for WPF and Silverlight that is deeply integrated...

SimpleMvvmToolkit.WPF                                                1.1.0.1                                                              Helper classes, Visual Studio templates, code snippets and sampl...

SimpleMvvmToolkit.WPF                                                1.1.0.2                                                              Helper classes, Visual Studio templates, code snippets and sampl...

SimpleMvvmToolkit.WPF                                                1.1.5.0                                                              Helper classes, Visual Studio templates, code snippets and sampl...

I then did the same thing for Silverlight:

PM> get-package -remote -filter silverlight

Id Version Description

-- ------- -----------

BingMapAppSDK 1.0.1011.1716 With the Bing Map App SDK, you can now create your own map apps ...

Catel.Silverlight 1.0.0 Silverlight version of Catel, including all controls and the MVV...

EF4Templates 1.1.0.1 EF4 Templates uses T4toolbox to generate Repositories, Unit of w...

entile-client 0.1.0 The Entile Notification Framework helps you when doing Live Tile...

FlickrNet.Silverlight 3.1.4000 The Flickr.Net API Library is a .Net Library for accessing the F...

FluentAssertions 1.3.0.1 A very extensive set of extension methods for .NET 3.5, 4.0 and ...

FluentValidation 1.3.0.0 A validation library for .NET, Silverlight and WP7 that uses a f...

FluentValidation 2.0.0.0 A validation library for .NET, Silverlight and WP7 that uses a f...

jLight 0.1 Interop between Silverlight and the javascript based on jQuery. ...

Moq 4.0.10827 The simplest mocking library for .NET 3.5/4.0 and Silverlight wi...

MvvmLight 3.0.0.29166 The MVVM Light Toolkit is a set of components helping people to ...

MVVMT4 1.0.0.0 T4 Templates for generating view models, and views for WPF, Silv...

Prism 4.0.0.0 Prism helps you more easily design and build rich, flexible, and...

protobuf-net 1.0.0.280 protocol buffers is the name of the binary serialization format ...

qdfeed 1.0.2 A lightweight .NET library designed to give developers an agnost...

ReactiveOAuth 0.2.0.0 Reactive Extensions base OAuth library for .NET Framework 4 Clie...

reactiveui 2.0.0.2 An MVVM library for WPF and Silverlight that is deeply integrate...

reactiveui-xaml 2.0.0.2 WPF and Silverlight specific extensions to ReactiveUI, formerly ...

reactivexaml 1.4.0.0 A MVVM library for WPF and Silverlight that is deeply integrated...

reactivexaml 1.4.1.0 A MVVM library for WPF and Silverlight that is deeply integrated...

SilverlightToolkit-All 4.2010.4 The complete Microsoft Silverlight Toolkit. Details at http://s...

SilverlightToolkit-Core 4.2010.4 The core components Microsoft Silverlight Toolkit. Details at h...

SilverlightToolkit-Data 4.2010.4 Data components of the Microsoft Silverlight Toolkit. Details a...

SilverlightToolkit-DataViz 4.2010.4 Data visualization components of the Microsoft Silverlight Toolk...

SilverlightToolkit-Input 4.2010.4 Input components of the Microsoft Silverlight Toolkit. Details ...

SilverlightToolkit-Layout 4.2010.4 Layout components of the Microsoft Silverlight Toolkit. Details...

SilverlightToolkit-Theming 4.2010.4 Theming components of the Microsoft Silverlight Toolkit. Detail...

SilverlightToolkitWP 4.2010.11 The Microsoft Silverlight for Windows Phone Toolkit. Details at...

SimpleMvvmToolkit.Silverlight 1.1.0.1 Helper classes, Visual Studio templates, code snippets and sampl...

SimpleMvvmToolkit.Silverlight 1.1.0.2 Helper classes, Visual Studio templates, code snippets and sampl...

SimpleMvvmToolkit.Silverlight 1.1.5.0 Helper classes, Visual Studio templates, code snippets and sampl...

StatLight 1.2.3919 StatLight: Tool for executing Silverlight test xap packages loca...

StatLight 1.3.3981 StatLight: Tool for executing Silverlight test xap packages loca...

There's a fair amount of stuff available for Silverlight as well. Very cool, indeed.

Step 3: Install a Package

There are a few WPF and Silverlight packages of interest there. Prism, ReactiveUI, Rx Extensions, the Silverlight Toolkit, SimpleMvvmToolkit, Windows 7 API Code Pack, and more. I'm going to install Prism, since it's interesting and has some dependencies that will need to be resolved.

First, if you haven't already, create a new WPF Windows app. Most NuGet packages need a project to install into.

Then, at the command prompt, type "install-package prism"

PM> install-package prism

'CommonServiceLocator (≥ 1.0)' not installed. Attempting to retrieve dependency from source...

Done

Successfully installed 'CommonServiceLocator 1.0'

You are downloading Prism from Microsoft patterns & practices, the license agreement to which is available at http://compositewpf.codeplex.com/license. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.

Successfully installed 'Prism 4.0.0.0'

Successfully added 'CommonServiceLocator 1.0' to WpfApplication2

Successfully added 'Prism 4.0.0.0' to WpfApplication2

The process took maybe 4 seconds at most (NuGet is really fast) and updated the references in my project, automatically including the correct libraries and, as you saw, installing any required dependencies. Due to the nature of NuGet packages at the moment, you typically don't get any templates. I hope to see that change in the future.

Step 4: Profit

If you're a tools or toolkit author, put your stuff in NuGet today. This is a great package management system (whether you use the command line or dialog approach) for Visual Studio. It saves you from having to deal with all the usual hunting and manual dependency referencing in your projects.

There's a lot of talk inside Microsoft about getting different projects and packages out on NuGet. Expect to see more soon.

If you're a developer using NuGet, you'll find it often quicker than using even the new add reference dialog. Definitely go try it out.

Enhancing the WPF Screen Capture Program with Window Borders

Pete Brown — Wed, 09 Feb 2011 20:52:42 GMT

In my previous post on creating a simple WPF Screen Capture program, I showed the basics of using the Win32 API and some WPF to take screen shots of other applications, regions on the screen, or the full screen. In this post, we'll enhance that sample to add a visible indicator of what window is being captured.

This example uses the full-screen almost-invisible WPF Window we created in the previous example. However, I've refactored the code and made a discrete window type. To the Window's xaml, I added the transparency properties as well as a red selection region.


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

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

        Height="300" Width="300"

        WindowStyle="None"

        ShowInTaskbar="False"

        AllowsTransparency="True"

        Topmost="True">

    

        
                   Visibility="Collapsed"

                   Stroke="Red"

                   StrokeThickness="3" />

Those window style and transparency settings were set in code in the previous version.

The capture window itself is very similar to what we had in the previous example. However, I added two events (discussed below), and the code to handle the highlight. Here's the highlight code:

private IntPtr _hoveredHWnd = IntPtr.Zero;

void CaptureWindow_MouseMove(object sender, MouseEventArgs e)

{

    Point current = e.GetPosition(this);

    Point screenCoords = PointToScreen(current);



    // this hide and show causes flicker, but using this

    // approach, there's not much you can do about that.

    // Caching the window rect doesn't help in the case of overlapping

    // windows. One thing you could do is run through and cache *all*

    // window rects. You could do some interesting things with that

    // but unless you restrict yourself to top-level windows, you'll

    // have a lot of rects to deal with

    Hide();



    IntPtr hWnd = User32.WindowFromPoint(new Win32Point((int)screenCoords.X, (int)screenCoords.Y));



    Show();



    if (hWnd != IntPtr.Zero)

    {

        // don't bother changing things if this is the same

        // window we've been over

        if (hWnd != _hoveredHWnd)

        {

            // get the dimensions of the window we're hovered over

            Win32Rect rect = new Win32Rect();

            User32.GetWindowRect(hWnd, out rect);



            Point topLeft = PointFromScreen(new Point(rect.Left, rect.Top));

                  



            WindowHighlight.Width = rect.Width;

            WindowHighlight.Height = rect.Height;

            WindowHighlight.Margin = new Thickness(

                topLeft.X,

                topLeft.Y,

                Width - rect.Width - topLeft.X,

                Height - rect.Height - topLeft.Y);



            WindowHighlight.Visibility = Visibility.Visible;

        }

    }

}

This code hides the window, calls the API call to get the hWnd under the mouse cursor, then, if the window isn't already selected, sizes and moves the red rectangle to highlight the bounds of that hWnd. To be clear, there is a fair amount of flicker when you keep the mouse relatively steady over the same window. I need to do something about that.

As I mentioned, the selection code itself is very similar to what we had before, but with the addition of WindowSelected and Canceled events.

private Point _mouseDown;

void CaptureWindow_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)

{

    _mouseDown = e.GetPosition(this);

}



void CaptureWindow_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)

{

    Point current = e.GetPosition(this);



    if (Math.Abs(_mouseDown.X - current.X) < 10.0 &&

        Math.Abs(_mouseDown.Y - current.Y) < 10.0)

    {

        // this is the window they want



        Point screenCoords = PointToScreen(current);

        Hide();



        IntPtr hWnd = User32.WindowFromPoint(new Win32Point((int)screenCoords.X, (int)screenCoords.Y));

        User32.SetForegroundWindow(hWnd);



        SelectedHWnd = hWnd;



        OnWindowSelected();

    }

}



protected void OnWindowSelected()

{

    if (WindowSelected != null)

        WindowSelected(this, EventArgs.Empty);

}

The attached source code includes the cancel and event wire-up code as well.

I then modified the calling code in the main window to use the new window and sink the new events. Originally, I had this as a modal window with a regular DialogResult. However, due to the need to actually hide the window before making the Win32 API call (setting visibility or opacity wouldn't work), and re-show it, that doesn't work. So, I went from a modal approach to an event-driven approach.

In this partial screen shot (taken with normal print screen) you can see the red selection highlight around Visual Studio.

Note that as was the case in the previous version of the code, the calls here do not restrict you to the main window hWnd. I'll want to modify the code to do that for this specific scenario (where we're expanding the size to include the border and shadow), but still retain an "any hWnd" mode, as that's pretty useful as well.

The Clipboard functionality is still disabled. I'll address that in an upcoming post. I promise! :)

Capturing Screen Images in WPF using GDI, Win32 and a little WPF Interop Help

Pete Brown — Tue, 08 Feb 2011 05:14:41 GMT

I keep a backlog of project/blog/video ideas on my machine here. One that I've had sitting there for a bit, and something that really interests me, is how to create a simple screen capture (still image) program using WPF.

I use a ton of screen shots in my applications. Before I joined Microsoft (when I was an MVP), I used Snag-it for just about everything. On this new machine, I haven't installed any screen capture apps at all. However, tools like Rooler by Pete Blois and Cropper up on CodePlex would be good candidates.

Of course, I want to build one myself anyway to learn how it's done. So, let's have at it.

Capturing a Region

The first task I decided to tackle is that of snap-shotting a region of the screen. Here's an example of a region which includes part of Visual Studio.

I wanted to keep it simple, so I didn't implement rubber-band selection or anything. A real app, of course, would need that. Instead, I decided just to hard-code the rectangle and test out the rest of the code from there.

There are three buttons, an Image and a Border in the Xaml. The one button we're concerned with for this example is the CaptureRegion button. It and the image are defined as follows:

Note the RenderOptions.BitmapScalingMode setting on the Image. When displaying we're typically resizing an image by far more than 50%, so you want a more aggressive smoothing algorithm. See more on my posts about image resizing in WPF 4 here and here.

For this example, I implemented the call in code-behind.

private void CaptureRegionButton_Click(object sender, RoutedEventArgs e)

{

    CapturedImage.Source = ScreenCapture.CaptureRegion(100, 100, 500, 500, true);

}

You can see that we're capturing a region starting at 100x100 with a size of 500,500. The last parameter says to copy to the clipboard -- more on that later.

Now for the important part. Capturing the region. This involves grabbing the desktop window, since a region may overlap windows, and rendering a portion of that to a bitmap. While much of it is Win32 API gunk (I'll leave out the Win32 API declarations; you can see them in the source code attached to this post), there's one really nice helper from WPF: the Imaging interop class.

// capture a region of a the screen, defined by the hWnd

public static BitmapSource CaptureRegion(

    IntPtr hWnd, int x, int y, int width, int height, bool addToClipboard)

{

    IntPtr sourceDC = IntPtr.Zero;

    IntPtr targetDC = IntPtr.Zero;

    IntPtr compatibleBitmapHandle = IntPtr.Zero;

    BitmapSource bitmap = null;



    try

    {

        // gets the main desktop and all open windows

        sourceDC = User32.GetDC(User32.GetDesktopWindow());

        //sourceDC = User32.GetDC(hWnd);

        targetDC = Gdi32.CreateCompatibleDC(sourceDC);



        // create a bitmap compatible with our target DC

        compatibleBitmapHandle = Gdi32.CreateCompatibleBitmap(sourceDC, width, height);



        // gets the bitmap into the target device context

        Gdi32.SelectObject(targetDC, compatibleBitmapHandle);



        // copy from source to destination

        Gdi32.BitBlt(targetDC, 0, 0, width, height, sourceDC, x, y, Gdi32.SRCCOPY);



        // Here's the WPF glue to make it all work. It converts from an

        // hBitmap to a BitmapSource. Love the WPF interop functions

        bitmap = System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(

            compatibleBitmapHandle, IntPtr.Zero, Int32Rect.Empty,

            BitmapSizeOptions.FromEmptyOptions());

             





    }

    catch (Exception ex)

    {

        throw new ScreenCaptureException(string.Format("Error capturing region {0},{1},{2},{3}", x, y, width, height), ex);

    }

    finally

    {

        Gdi32.DeleteObject(compatibleBitmapHandle);



        User32.ReleaseDC(IntPtr.Zero, sourceDC);

        User32.ReleaseDC(IntPtr.Zero, targetDC);

    }



    return bitmap;

}

We use the Imaging interop class to create a WPF-compatible BitmapSource from a Windows hBitmap. Note that I'm not doing anything with the Clipboard parameter in this code. The clipboard portion is not yet working, but is included in the source code.

That's all there is to capturing a region. It's super simple once you realize there's this great helper functionality included in the WPF interop namespace.

Next, we'll expand this to capture the entire screen.

Capturing the Entire Screen

The second thing I decided to do is implement a simple Print-Screen function which snapshots the entire virtual screen space. Here's an example of a screen shot from this machine:

You can see from the above screenshot that I have two displays stacked on each other. Windows does a good job of providing both images, with appropriate transparency where no display occupies that space.

The nice part about this is it uses the existing CaptureRegion function to do all the heavy lifting:

public static BitmapSource CaptureFullScreen(bool addToClipboard)

{

    return CaptureRegion(

        User32.GetDesktopWindow(),

        (int)SystemParameters.VirtualScreenLeft,

        (int)SystemParameters.VirtualScreenTop,

        (int)SystemParameters.VirtualScreenWidth,

        (int)SystemParameters.VirtualScreenHeight,

        addToClipboard);

}

The key thing to note in this chunk of code is the SystemParameters object which provides the size of the full screen.

The next task is to capture a single window. This is where things start getting hairy.

Capturing a Single Window

I'm not a fan of Alt-PrtScn to capture a single window. When you do that, you lose the nice shadow effect from Windows 7 and Vista, and get an ugly chopped image with dark corners (since it leave the shadow there, but doesn't mask the rounded corners). Here's an example:

Not only do we have the corner problem, but due to aero glass, background content shows through. On a full desktop, that content adds context, but in a screenshot, it just looks messy. Screenshots like that just look unprofessional. I did my best to make sure they don't show up in my books or on my blog.

The attached source code has the start of a blanking approach: I stick a blank window behind the target window before doing the screen shot. It's not stable and suffers from a race condition, so I'll not include that code in this blog post. However, I will show you how to capture the full window including the shadow.

Warning: Lark's Vomit!

(that was a Big Red Label. Look it up )

Ok, seriously. This code has magic numbers. I hate magic numbers. There is likely a nice systemic way to retrieve the exact dimensions I need, including shadows and whatnot. However, it eludes me at the moment. Use the code if you want, but realize you're inheriting disease. Don't blame me if you implement a mission critical print-screen hospital patient monitoring system and someone gets +/- 5% dosage or something ;)

First, the main window capture function (with blanking window code removed):

public static BitmapSource CaptureWindow(IntPtr hWnd, bool recolorBackground, Color substituteBackgroundColor, bool addToClipboard)

{

    Int32Rect rect = GetWindowActualRect(hWnd);



    Window blankingWindow = null;



    if (recolorBackground)

    {

        // ... blanking window gunk ...

    }



    // bring the to-be-captured window to capture to the foreground

    // there's a race condition here where the blanking window

    // sometimes comes to the top. Hate those. There is surely

    // a non-WPF native solution to the blanking window which likely

    // involves drawing directly on the desktop or the target window

         

    User32.SetForegroundWindow(hWnd);



    BitmapSource captured = CaptureRegion(

        hWnd,

        rect.X,

        rect.Y,

        rect.Width,

        rect.Height,

        true);



    if (blankingWindow != null)

        blankingWindow.Close();



    return captured;

}

One function in there deserves calling-out: GetWindowActualRect. This is where the majority of fudging happens

// this accounts for the border and shadow. Serious fudgery here.

private static Int32Rect GetWindowActualRect(IntPtr hWnd)

{

    Win32Rect windowRect = new Win32Rect();

    Win32Rect clientRect = new Win32Rect();



    User32.GetWindowRect(hWnd, out windowRect);

    User32.GetClientRect(hWnd, out clientRect);



    int sideBorder = (windowRect.Width - clientRect.Width)/2 + 1;



    // sooo, yeah.

    const int hackToAccountForShadow = 4;



    Win32Point topLeftPoint = new Win32Point(windowRect.Left - sideBorder, windowRect.Top - sideBorder);



    //User32.ClientToScreen(hWnd, ref topLeftPoint);



    Int32Rect actualRect = new Int32Rect(

        topLeftPoint.X,

        topLeftPoint.Y,

        windowRect.Width + sideBorder * 2 + hackToAccountForShadow,

        windowRect.Height + sideBorder * 2 + hackToAccountForShadow);



    return actualRect;

}

There are a couple problems related to the magic numbers:

You can incorrect results with maximized windows. I can check for this and handle it in code.
Some windows just don't cooperate with this. Again, Windows Live Writer is one that throws me. Most of the other Windows all behave nicely, but the WLW window ends up shifted over a few pixels.
This hasn't been tested on Aero Basic
When you click on child hWnds (like the web page inside the browser, or the editor inside Visual Studio) the fudge numbers no longer make sense.

Other than that, it does a decent job of capturing the window itself, including its aero borders and shadows.

Once we have the actual bounds of the window (including shadows), the code simply calls the same CaptureRegion code from before. Here's an example of capturing the Visual Studio window.

Without the white blanking window in the background, it looks ugly, I know. That is a solvable problem and will be dealt with.

But wait, how did I go about picking that particular window for capture? Ahh, that's the next part :)

Picking a Window with the Mouse

I didn't want this to be a completely academic exercise, so I figured I had better put in some realistic functionality. That comes in the form of using the mouse to select the window you want to capture.

private void CaptureWindowWithBackgroundButton_Click(object sender, RoutedEventArgs e)

{

    PickWindowWithMouse();

}



private void PickWindowWithMouse()

{

    Window captureWindow = new Window();



    captureWindow.WindowStyle = WindowStyle.None;

    captureWindow.Title = string.Empty;

    captureWindow.ShowInTaskbar = false;

    captureWindow.AllowsTransparency = true;

    captureWindow.Background = new SolidColorBrush(Color.FromArgb(0x01, 0x00, 0x00, 0x00));

    captureWindow.Topmost = true;



    captureWindow.Left = SystemParameters.VirtualScreenLeft;

    captureWindow.Top = SystemParameters.VirtualScreenTop;

    captureWindow.Width = SystemParameters.VirtualScreenWidth;

    captureWindow.Height = SystemParameters.VirtualScreenHeight;



    Point mouseDown = new Point();



    captureWindow.KeyUp += (s, e) =>

        {

            if (e.Key == Key.Escape)

            {

                // cancel the capture

                captureWindow.Close();

                this.Show();

            }

        };



    captureWindow.MouseDown += (s, e) =>

        {

            mouseDown = e.GetPosition(captureWindow);

        };



    captureWindow.MouseUp += (s, e) =>

        {

            Point current = e.GetPosition(captureWindow);



            if (Math.Abs(mouseDown.X - current.X) < 10.0 &&

                Math.Abs(mouseDown.Y - current.Y) < 10.0)

            {

                // this is the window they want



                Point screenCoords = captureWindow.PointToScreen(current);

                captureWindow.Close();



                IntPtr hWnd = User32.WindowFromPoint(new Win32Point((int)screenCoords.X, (int)screenCoords.Y));

                User32.SetForegroundWindow(hWnd);



                //CapturedImage.Source = ScreenCapture.CaptureWindow(hWnd, true, Colors.White, true);

                CapturedImage.Source = ScreenCapture.CaptureWindow(hWnd, false, Colors.Transparent, true);



                // show our app window again, and bring it to the foreground

                WindowInteropHelper helper = new WindowInteropHelper(this);

                this.Show();

                User32.SetForegroundWindow(helper.Handle);

                     

            }

        };



    this.Hide();

    captureWindow.Show();



}

To handle this, I create a full-screen WPF window and use it to capture the click. Windows don't have a click event, so I check to see if the MouseUp event is raised within 10 pixels of the MouseDown event. The window covers the entire screen, so I don't bother with capturing the mouse.

I then use the Win32 API to map that click to a hWnd in Windows. That hWnd doesn't always resolve to a top-level application. For example, IE8: if I click in the web page, the only part that is captured is the rendered web page (the portion viewable on-screen). I have to click in the title bar or tool bar to get the full IE window.

So, in a nutshell:

Hide this app window
Show the capture window
Capture the mouse click
Hide the capture window
Map the mouse click to an app
Bring that app to the front (so whole window is visible)
Capture the image
Show my app's window again
Bring my app's window to the front

The user can press escape at any time to close the capture window.

The full-screen WPF window is not the only available option. However, I'll want to have that available for rubber band selection and other possible enhancements in the future, so using it here imposes no hard tax.

Features that are Not Quite Working

As mentioned, the code has some additional stuff not shown here. It's not shown because it's not working that well. The first is the ability to add a blanking window behind the window being captured. This is good for getting nice clean screenshots, typically on a white background. When taking normal screen shots using Print-Screen, I manually do this by hovering the window over notepad when using print screen. Crude, but works. I want a better solution.

The second bit is the clipboard. I wrestled with the clipboard tonight but couldn't get it to put a good default format in that was recognized by Windows Live Writer. As written, it will paste into MS Word and even MS Paint. WLW, on the other hand, doesn't recognize what's there. Obviously something's amiss.

So, expect a follow-up should I come up with decent solutions for these issues. Feel free to tinker with the code on your own as well.

Windows File Dialog Custom Places in WPF 4

Pete Brown — Sat, 29 Jan 2011 21:01:02 GMT

Starting with Windows Vista, the open and save file dialog boxes have a panel on the left side containing favorite links. These links are known as "Custom Places". Previously, the built-in Windows dialogs were available only if you used the Windows Forms versions. However, starting with WPF 4 on Windows 7 and Windows Vista support of native file dialogs with custom places via the FileDialogCustomPlace and FileDialogCustomPlaces classes can be found in the Microsoft.Win32 namespace right in the PresentationFramework dll.

Using Standard Custom Places

The framework includes a number of built-in custom places, representing the usual system and user locations on the machine, plus the local and roaming profile locations. To use them, simply use the static instances provided by the FileDialogCustomPlaces class.

private void SaveButton_Click(object sender, RoutedEventArgs e)

{

    SaveFileDialog dialog = new SaveFileDialog();



    dialog.CustomPlaces.Add(FileDialogCustomPlaces.LocalApplicationData);

    dialog.CustomPlaces.Add(FileDialogCustomPlaces.Templates);



    dialog.ShowDialog();

}

When displayed, the dialog will have two custom places shown at the top left (refer to screen shot in the next section): the local application data folder and the templates folder.

The standard places supplied are (from MSDN) :

Name	Description
Contacts	Contacts folder for the current user.
Cookies	Internet cookies folder for the current user.
Desktop	Folder for storing files on the desktop for the current user.
Documents	Documents folder for the current user.
Favorites	Favorites folder for the current user.
LocalApplicationData	Folder for application-specific data that is used by the current, non-roaming user.
Music	Music folder for the current user.
Pictures	Pictures folder for the current user.
ProgramFiles	Program Files folder.
ProgramFilesCommon	Folder for components that are shared across applications.
Programs	Folder that contains the program groups for the current user.
RoamingApplicationData	Folder for application-specific data for the current roaming user.
SendTo	Folder that contains the Send To menu items for the current user.
StartMenu	Folder that contains the Start menu items for the current user.
Startup	Folder that corresponds to the Startup program group for the current user.
System	System folder.
Templates	Folder for document templates for the current user.

While the standard places will suffice for most applications, especially since they include the local application data folder, you may wish to provide additional locations. This is accomplished via the FileDialogCustomPlace class.

Adding Your Own Places

Sometimes the built-in places aren't sufficient for all the locations you'd like to surface to the user. For example, I have some software recording/sequencing applications. Many of those share the same folder for plug-ins, known as VSTs. I may want to provide the ability for the user to quickly locate that folder in the open and save file dialogs. This is accomplished by creating an instance of the FileDialogCustomPlace class.

private void SaveButton_Click(object sender, RoutedEventArgs e)

{

    SaveFileDialog dialog = new SaveFileDialog();



    string appSpecialPath = @"C:\Program Files (x86)\Image-Line\FL Studio 9\Plugins\VST";



    FileDialogCustomPlace place = new FileDialogCustomPlace(appSpecialPath);



    dialog.CustomPlaces.Add(place);

    dialog.CustomPlaces.Add(FileDialogCustomPlaces.LocalApplicationData);

    dialog.CustomPlaces.Add(FileDialogCustomPlaces.Templates);



    dialog.ShowDialog();



}

The FileDialogCustomPlace class constructor takes in either a string path or a GUID which refers to one of the built-in places. In this case, I supplied it with the VST plug-in folder. When run, the dialog looks like this:

Note that the name of the folder is displayed using normal Windows mechanisms: you get just the name of the final folder in the path.

Also note that on Windows XP, the custom places will have no effect. The feature is gracefully dropped.

Puff the Magic POCO Binding and INotifyPropertyChanged in WPF

Pete Brown — Fri, 17 Dec 2010 18:27:28 GMT

Yesterday I wrote a post about different ways of working with INotifyPropertyChanged. One of my readers (who only went by "Guest") pointed out that binding "magically" worked in WPF with POCOs (Plain Old CLR Objects) that didn't bother to implement INotifyPropertyChanged. I thought for sure he/she was wrong … until I tried it myself. Magic, I say! Magic!

Then again, as one of the WPF team members pointed out to me, this is a great example of Clarke's third law. :)

Take this example:


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

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

        Title="MainWindow" Height="350" Width="525">

    

        
                 Height="287"

                 HorizontalAlignment="Left"

                 DisplayMemberPath="LastName"

                 Margin="12,12,0,0"

                 VerticalAlignment="Top"

                 Width="138" />

        
                 HorizontalAlignment="Left"

                 Margin="265,24,0,0"

                 x:Name="LastNameField"

                 VerticalAlignment="Top"

                 DataContext="{Binding ElementName=PeopleList, Path=SelectedItem}"

                 Text="{Binding LastName}"

                 Width="120" />

        
                   HorizontalAlignment="Left"

                   Margin="178,27,0,0"

                   Text="Last Name"

                   VerticalAlignment="Top" />

Here's the Person Class

class Person

{

    public string FirstName { get; set; }

    public string LastName { get; set; }

}

Here's the Code-behind

public partial class MainWindow : Window

{

    private ObservableCollection _people;



    public MainWindow()

    {

        InitializeComponent();



        _people = new ObservableCollection();



        _people.Add(new Person() { LastName = "Brown" });

        _people.Add(new Person() { LastName = "Fitz" });

        _people.Add(new Person() { LastName = "Hanselman" });

        _people.Add(new Person() { LastName = "Heuer" });

        _people.Add(new Person() { LastName = "Galloway" });

        _people.Add(new Person() { LastName = "Stagner" });

        _people.Add(new Person() { LastName = "Liberty" });

        _people.Add(new Person() { LastName = "Litwin" });

        _people.Add(new Person() { LastName = "Papa" });

        _people.Add(new Person() { LastName = "Guthrie" });



        PeopleList.ItemsSource = _people;

    }

}

When you run this little application, and modify the value in the TextBox, the value in the ListBox is updated, seemingly by magic.

There it is. The value in the ListBox updated right when I tabbed off of the last name field. Magic code? Spirits? Too much alcohol? What is happening here?

What's Really Happening

The Person class has a PropertyDescriptor for each property. The PropertyDescriptor has the AddValueChanged method by which a listener can sign up to get the property change notifications from that descriptor. That's what the behind-the-scenes binding is doing - wiring up a value changed event for the property descriptor in play in the binding.

Note this only works when using binding. If you update the values from code, the change won't be notified.

What's happening is actually a perfectly valid (if not optimal) way to handle binding and change notification. What WPF is doing behind the scenes in this case is something you could explicitly put in your own code if you wish.

Implications

The PropertyDescriptor class is pretty heavy. In addition, WPF must request the full set of descriptors for the class, not just a single descriptor. If you have a class with a large number of properties, regardless of how many are actually involved in binding, the CPU and memory usage associated with that call can be both significant and measurable. In one instance, the memory used to get all the property descriptors for a large class was around 800K!

But doesn't WPF need that for binding anyway?

No. WPF uses the much lighter weight PropertyInfo class when binding. If you explicitly implement INotifyPropertyChanged, all WPF needs to do is call the PropertyInfo.GetValue method to get the latest value. That's quite a bit less work than getting all the descriptors. Descriptors end up costing in the order of 4x the memory of the property info classes.

Note also that if you have a reference from the POCO back in the UI (we don't do that, right…right?) you may be subject to the memory leak described in KB938416. That only applies to the PropertyDescriptor-based approach, which in this post, is POCO only.

Summary

Implementing INotifyPropertyChanged can be a fair bit of tedious development work. However, you'll need to weigh that work against the runtime footprint (memory and CPU) of your WPF application. Implementing INPC yourself will save runtime CPU and memory.

Thanks to the WPF team for the detailed information about what's going on here. I love being able to talk to the people who actually wrote the code :)

Note that Silverlight does not have the PropertyDescriptor class, so this doesn't apply there.

Strategies for Improving INotifyPropertyChanged in WPF and Silverlight

Pete Brown — Thu, 16 Dec 2010 17:38:00 GMT

The Silverlight and WPF binding system is extremely powerful. With it, you can bind your UI to your viewmodels (or other backing objects), bind control values to each other (for example, a slider controlling an object's scale or rotation) all with little or no code.

In order for binding to work, it requires a little cooperation from code. The target of a binding statement (typically a property of some bit of the UI) must be a dependency property - that is, an implemented instance of DependencyProperty which can get its value from external sources. Similarly, the source of the binding must be able to notify that the value has changed. In the UI layer, this is typically a DependencyProperty, but in your non-UI objects, you'll need to implement INotifyPropertyChanged (often called "INPC") and raise an event whenever values change. Why? Because any class which has Dependency Properties must derive from DependencyObject, a constraint which makes no sense in entities, viewmodel and business-layer classes.

Basic, Verbose, INPC Example

Here's an example using INPC in a viewmodel class.

public class BasicApproach : INotifyPropertyChanged

{

    private int _level;

    public int Level

    {

        get { return _level; }

        set

        {

            if (_level != value)

            {

                _level = value;

                NotifyPropertyChanged("Level");

            }

        }

    }



    private string _lastName;

    public string LastName

    {

        get { return _lastName; }

        set

        {

            if (_lastName != value)

            {

                _lastName = value;

                NotifyPropertyChanged("LastName");

                NotifyPropertyChanged("FullName");

            }

        }

    }



    private string _firstName;

    public string FirstName

    {

        get { return _firstName; }

        set

        {

            if (_firstName != value)

            {

                _firstName = value;

                NotifyPropertyChanged("FirstName");

                NotifyPropertyChanged("FullName");

            }

        }

    }



    public string FullName

    {

        get { return FirstName + " " + LastName; }

    }





    public event PropertyChangedEventHandler PropertyChanged;



    protected void NotifyPropertyChanged(string propertyName)

    {

        if (PropertyChanged != null)

            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

    }

}

Typically I'll refactor this so I have an abstract base class named Observable which contains the interface and event-raising function. Nevertheless, this code is tedious and error-prone. It's tedious because you have to expand properties which would have been fine as auto-props. It's error-prone because you need to pass the string name of the property to the event. If you make a typo or change the name of the property without changing the string, binding will never be notified that the property changed.

The string-based approach, however, was the best for the framework developers because it is flexible, very fast, and gives you the option to implement other approaches on top of it.

Other folks have come up with their own base classes, many of which include optimizations to avoid creating so many instances of the PropertyChangedEventArgs class and include helpful checking information using reflection when in debug mode. Here's an example from Josh Smith. One nice thing about Josh's approach is that takes a performance hit primarily when in debug mode, not release mode.

There are several other elegant approaches to solving this. Let's look at the common reflection and lambda approach first.

Using Reflection and Lambda Expressions

One particularly slick approach uses both reflection and lambda expressions to add in a compile-time check on the property name.

public class ReflectionLambdaApproach : INotifyPropertyChanged

{

    private int _level;

    public int Level

    {

        get { return _level; }

        set

        {

            if (_level != value)

            {

                _level = value;

                NotifyPropertyChanged(() => Level);

            }

        }

    }



    private string _lastName;

    public string LastName

    {

        get { return _lastName; }

        set

        {

            if (_lastName != value)

            {

                _lastName = value;

                NotifyPropertyChanged(() => LastName);

                NotifyPropertyChanged(() => FullName);

            }

        }

    }



    private string _firstName;

    public string FirstName

    {

        get { return _firstName; }

        set

        {

            if (_firstName != value)

            {

                _firstName = value;

                NotifyPropertyChanged(() => FirstName);

                NotifyPropertyChanged(() => FullName);

            }

        }

    }



    public string FullName

    {

        get { return FirstName + " " + LastName; }

    }







    public event PropertyChangedEventHandler PropertyChanged;



    public void NotifyPropertyChanged(Expression> property)

    {

        if (PropertyChanged != null)

        {

            var memberExpression = property.Body as MemberExpression;



            PropertyChanged(this, new PropertyChangedEventArgs(memberExpression.Member.Name));

        }

    }

}

Now, as this does use reflection, it is much slower than the hard-coded version. You need to be very aware of this because the PropertyChanged event can be raised a large number of times in a class. You'll need to make a decision based on how you will use this in your project.

One optimization to this approach would be to cache the property descriptor information so you reflect on it only once. Another common optimization is to wrap all the code into a SetProperty (or similar) method (and this update) which handles the property value checking, assignment, and event raising.

In any case, the amount of code doesn't change significantly unless you use the SetProperty approach. What you've gained by this approach is compile-time checking of the property names - a non-trivial improvement. Another approach which gives us both the checking and the code reduction and which has gained traction lately is IL Weaving. This injects property changed information into the IL rather than into the source code.

Using IL Weaving

The ins and outs of IL Weaving is too much to include in this post. However, I want to refer you to Justin Angel's great post on the topic. Justin goes through from the top down to what it takes to use MSIL Weaving in your own project. Be sure to read the comments as well.

When using weaving, you can go back to using auto-properties and leave out all the INPC gunk. It does have its limitations, though. In the examples you'll find, it doesn't do anything for dependent properties like our FullName property. You can certainly expand the examples to include something like that, but I haven't seen it done.

Now, despite weaving not doing anything for our FullName property, that's a heck of a lot cleaner than the other approaches we've been using. It handles the majority of simple cases where the properties are not dependent upon each other.

Summary

There are tons of other approaches, including this interesting AutoPropertyChanged approach on codeproject and this post by Jonas on using a dynamic proxy and Ninject to do the dirty work. This post is by no means a survey of all of those, but instead a summary of a couple common approaches. I've seen some really slick implementations that go above and beyond what I've done here, so be sure to check them out. A simple bing search for INotifyPropertyChanged will show you a ton of examples.

In addition, most MVVM frameworks have taken one of these approaches and built upon it to make your life easier. That's one of the benefits of picking a MVVM framework when using that pattern with Silverlight and WPF.

The WPF team is also considering possible approaches for this. No promises, but it is on their radar :)

If you have a favorite approach I haven't mentioned here, feel free to link to it or describe it in the comments.

There's no downloadable source for this post on purpose. Don't use this code directly, instead go check out some of the more robust implementations out there. :)

Dynamically Generating Controls in WPF and Silverlight

Pete Brown — Wed, 08 Dec 2010 20:28:47 GMT

Some of the Windows Forms developers I've spoken to have said that one thing they want to learn is how to dynamically create controls in WPF and Silverlight. In this post I'll show you several different ways to create controls at runtime using Silverlight 4 and WPF 4.

First, we'll start with how to create controls in XAML. From there, we'll move to dynamically-loaded XAML before we take a look at using the CLR object equivalents.

Creating Controls at Design Time in XAML

Creating controls using the design surface and/or XAML editor is definitely the easiest way to create your UI. You can use Expression Blend or Visual Studio, depending upon how creative you want to be. If you want a more dynamic layout, you can hide and show panels at runtime.

Here's an example layout:

That markup creates a layout that looks like this in Silverlight:

Or, if you're using WPF, like this:

(note that you'll need to remove or remap the "sdk" prefix when using this XAML in WPF, as the date control is built-in)

Once you're familiar with working in XAML, you can easily modify the process to load the XAML at runtime to dynamically create controls.

Creating Controls at runtime using XAML strings

In Silverlight, this block of code in the code-behind creates the same controls at runtime by loading the XAML from a string using the System.Windows.Markup.XamlReader class. This class exposes a Load method which (in Silverlight) takes a well-formed and valid XAML string and returns back a visual tree

public MainPage()
{
    InitializeComponent();

    Loaded += new RoutedEventHandler(MainPage_Loaded);
}

void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    CreateControls();
}


private void CreateControls()
{
    string xaml =
    "" + 
        "" +
            "" +
            "" +
        "" +

        "" +
            "" +
            "" +
            "" +
            "" +
        "" +

        "" +
        "" +

        "" +
        "" +

        "" +
        "" +

        "

Note that I needed to add the namespace definitions directly in this XAML. A chunk of XAML loaded via XamlReader.Load must be completely self-contained and syntactically correct.

The WPF XamlReader.Load call is slightly different as it has no overload which would take a string. Instead, it takes an XmlReader as one form of parameter:

StringReader stringReader = new StringReader(xaml);
XmlReader xmlReader = XmlReader.Create(stringReader);

UIElement tree = (UIElement)XamlReader.Load(xmlReader);

LayoutRoot.Children.Add(tree);

This technique also works for loading chunks of XAML from a file on the local machine, or as the result of a database query. It's also helpful for enabling the use of constants (like the extended color set) that are recognized by XAML parser in Silverlight, but not from code.

The more typical approach to dynamically creating controls, however, is to simply use the CLR objects.

Creating Controls at runtime using Code and CLR Objects

Everything you do in XAML can also be done from code. XAML is a representation of CLR objects, rather than a markup language that abstracts the underlying objects. Creating controls from code tends to be more verbose than doing the same from XAML. However, it is a familiar approach for Windows Forms developers, and a great way to handle dynamic UI.

private void CreateControlsUsingObjects()
{
    // 
    Grid rootGrid = new Grid();
    rootGrid.Margin = new Thickness(10.0);
            
    // 
    //   
    //   
    //

    rootGrid.ColumnDefinitions.Add(
        new ColumnDefinition() { Width = new GridLength(100.0) });
    rootGrid.ColumnDefinitions.Add(
        new ColumnDefinition() { Width = new GridLength(1, GridUnitType.Star) });

    //
    //  
    //  
    //  
    //  
    //

    rootGrid.RowDefinitions.Add(
        new RowDefinition() { Height = GridLength.Auto });
    rootGrid.RowDefinitions.Add(
        new RowDefinition() { Height = GridLength.Auto });
    rootGrid.RowDefinitions.Add(
        new RowDefinition() { Height = GridLength.Auto });
    rootGrid.RowDefinitions.Add(
        new RowDefinition() { Height = new GridLength(1, GridUnitType.Star) });

    //

    var firstNameLabel = CreateTextBlock("First Name", 19, new Thickness(0, 7, 31, 4), 0, 0);
    rootGrid.Children.Add(firstNameLabel);

    //

    var firstNameField = CreateTextBox(new Thickness(3), 0, 1);
    rootGrid.Children.Add(firstNameField);

    //

    var lastNameLabel = CreateTextBlock("Last Name", 20, new Thickness(0, 7, 6, 3), 1, 0);
    rootGrid.Children.Add(lastNameLabel);

            
    //

    var lastNameField = CreateTextBox(new Thickness(3), 1, 1);
    rootGrid.Children.Add(lastNameField);


    //

    var dobLabel = CreateTextBlock("Date of Birth", 21, new Thickness(0, 9, 0, 0), 2, 0);
    rootGrid.Children.Add(dobLabel);

    //

    DatePicker picker = new DatePicker();
    picker.Margin = new Thickness(3);
    Grid.SetRow(picker, 2);
    Grid.SetColumn(picker, 1);
    rootGrid.Children.Add(picker);

    //

You'll see the code is only slightly more verbose when expanded out. The two helper functions help minimize that. In the code, I create the entire branch of the visual tree before I add it to the root. Doing this helps minimize layout cycles you'd otherwise have if you added each item individually to the root.

I tend to put any UI interaction inside the Loaded event. However, you could place this same code inside the constructor, after the InitializeComponent call. As your code gets more complex, and relies on other UI elements to be initialized and loaded, you'll want to be smart about which function you use.

Handling Events

If you want to handle events, like button clicks, you'd do that like any other .NET event handler:

{
    Button button = new Button();
    ...
    button.Click += new RoutedEventHandler(button_Click);

    LayoutRoot.Children.Add(rootGrid);
}

void button_Click(object sender, RoutedEventArgs e)
{
    ...
}

Creating controls from code doesn't mean you lose the valuable ability to data bind. In some cases, especially where the binding source is hard to reference from XAML, binding is easier in code.

Binding Dynamically Created Controls

We haven't used any binding yet, so we'll need to create a binding source. For that, I created a simple shared project that targets Silverlight 4. It's a Silverlight class library project and is used by both the WPF and Silverlight examples. Remember, to use it from WPF 4 (without any additions), you'll need to use a file reference to the compiled DLL, not a project reference.

Inside that project, I created a single ViewModel class named ExampleViewModel.

public class ExampleViewModel : INotifyPropertyChanged
{
    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set { _lastName = value; NotifyPropertyChanged("LastName"); }
    }

    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set { _firstName = value; NotifyPropertyChanged("FirstName"); }
    }

    private DateTime _dateOfBirth;
    public DateTime DateOfBirth
    {
        get { return _dateOfBirth; }
        set { _dateOfBirth = value; NotifyPropertyChanged("DateOfBirth"); }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    protected void NotifyPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

Inside the code-behind (this is a demo, after all) of the Window (or Page), initialize the viewmodel class:

private ExampleViewModel _vm = new ExampleViewModel();

public MainWindow()
{
    _vm.LastName = "Brown";
    _vm.FirstName = "Pete";
    _vm.DateOfBirth = DateTime.Parse("Jan 1, 1910");

    InitializeComponent();

    ...
}

Once that is done, we can create an example binding. I'm going to use the First Name TextBox and set up two-way binding with the FirstName property of the ExampleViewModel instance.

var firstNameField = CreateTextBox(new Thickness(3), 0, 1);
Binding firstNameBinding = new Binding();
firstNameBinding.Source = _vm;
firstNameBinding.Path = new PropertyPath("FirstName");
firstNameBinding.Mode = BindingMode.TwoWay;
firstNameField.SetBinding(TextBox.TextProperty, firstNameBinding);          

rootGrid.Children.Add(firstNameField);

The same approach to expressing binding also works in XAML. It's just that we have a binding markup extension that makes the process easier.

One thing that tripped me up in this example was I passed in TextBlock.TextProperty to the SetBinding call. That's a valid dependency property, so it compiles just fine. In WPF, that fails silently, even when you have verbose binding debugging turned on. In Silverlight, it throws a catastrophic error (without any additional information). That catastrophic error made me look more closely at the call, ultimately leading to the fix.

To bind controls added using dynamically-loaded XAML, you'll need to provide a valid Name to each control you want to reference, then use FindName after loading to get a reference to the control. From there, you can using the Binding object and SetBinding method. Of course, you can also embed the binding statements directly in the XAML if you wish to do a little string manipulation.

Summary

So, we've seen that there are three different ways you can display controls in Silverlight and WPF.

Use the design surface / XAML Editor / Blend and create them prior to compiling
Load XAML at runtime
Use CLR Objects at runtime

Each way is useful in different scenarios, and also has different performance characteristics. XAML parsing is surprisingly efficient and the XAML can be stored in a large text field in a single row in a database or as a loose file on the file system, for example.

For additional information on the layout system and the visual tree, please see the following

The attached zip file contains source for both Silverlight 4 and WPF 4.

Windows Forms to XAML: Do I really need a Designer for Silverlight or WPF Applications?

Pete Brown — Fri, 19 Nov 2010 06:25:24 GMT

I've made it a personal goal this coming year to help Windows Forms developers (who want to move) move to Silverlight and/or WPF.

A common sticking point for development shops planning to adopt Silverlight or WPF after years of work in something like Windows Forms, is that they feel they need a design professional on-team in order to build the same quality apps they've been used to building. After looking at some of the amazing consumer and ISV experiences being developed in Silverlight and WPF, I can certainly see why folks might get this impression.

The blank slate you get when first developing WPF or Silverlight applications can be intimidating. Suddenly, the sky's the limit. It's like you've worked with a single pencil your whole life, and have been suddenly delivered a huge box of crayons. Rather than just pick the black crayon and continue to draw much like you did with the pencil (with some obvious adjustments to account for the differences between a waxy crayon and a hard pencil), you feel like you really must use the whole set you've been given just to keep up with the Joneses.

At that point, many of us lock up and say simply "I can't do this. I don't know where to start" or "I've seen some awesome drawings using all these crayons, and I know I'm not yet good with colors". It's a crisis of self-confidence, and it gets in the way of learning something new. In many cases, the developers simply say that in order to use this new box of crayons, they must have an artist working with them. Otherwise, they're just going to stick with their pencil so as not to embarrass themselves with their color selection and technique.

While most any project in any technology (ASP.NET, Windows Forms, WPF, whatever) will benefit from good user experience designers and graphics designers, they are certainly not a requirement when you want to build the same comfortable battleship gray type apps (or ghost white) you're building in Windows Forms today.

Here's a representative business application in-development. Nothing special here: a treeview, a menu, status bar, a couple headers, a few fields and a datagrid. Very few companies would use a design professional when creating this (not saying that's ok, just typical) in Windows Forms. Those same companies or project teams wouldn't need a design professional to create this in WPF or Silverlight. In fact, throw a couple icons in there and a toolbar, and this looks very much like the Windows Forms 1.1 apps I built near the start of the decade.

There are no fancy carousels, no rotating widgets, no special effects. In fact, there are very few animations to begin with. Sure, once you learn the platform and some good UX patterns, you can augment your application with nice transitions and subtle animations, but it's not a requirement to get in the door. In fact, it's never really a requirement unless you get to a point where you want to make it so. It's your (and your customer's) choice.

Editor Support and Expression Blend

Another related concern is that developers think they have to use Expression Blend to do any UI work. Here's a screen shot of the VS2010 design surface, with a typical menu being built using the design tools. The XAML is shown at the bottom, but I've been using the design surface in this example. Not only is it productive, it's a great way to learn XAML syntax.

While I do enjoy working in Expression Blend, it isn't something you have to use when building these types of applications. The VS2010 editor's design surface combined with the ability to directly edit XAML is sufficient for all the Windows Forms equivalent design work you'll have to do. It will even help you with binding syntax, both in the XAML editor and, as shown here, on the design surface.

So, if you were able to design your Windows Forms apps using just the editor, you should feel comfortable that you'll be able to do the same with WPF or Silverlight in Visual Studio 2010. The property names will be a little different, and the concepts will take some adjusting to (I'm working on helping with all that), but the tooling is definitely there for you.

Now. If you want to take that application and create a truly differentiated user experience, then yes, you'll want design professionals working with you from the very start of the project, and you'll want someone working in Blend. The difference here is that WPF and Silverlight actually provide a good platform for you to work with those professionals while creating that experience whereas Windows Forms was not designed with that in mind.

(hint, install the Silverlight 4 tools to get some enhancements to the shared WPF and Silverlight editor)

Conclusion

Don't feel that just because it's Silverlight or WPF, you have to be super creative in your application design. In fact, your first couple projects should be conservative, using user experience patterns you've honed during years of Windows Forms experience.

If you're getting away without designers today, and don't need to create a truly differentiated or premium experience, then you don't need designers on your team when you move to WPF or Silverlight. The WPF editor is good enough for business application developers to do the vast majority of their UI layout work, dropping into the XAML editor from time to time only when it is the faster approach for you.

Creating an Office Communicator Application for Do Not Disturb

Pete Brown — Mon, 18 Oct 2010 01:22:35 GMT

When meeting with other people at Microsoft, my computer is also my phone. I rely on Office Communicator 2007 R2 more than many other applications.

Family members wandering into my home office can't really tell I'm on a call unless I happen to be talking right then. I normally have my headphones on anyway, and I use my Samson mic for voice. Usually my wife stands out of camera range and mimes "Are you on the phone?". My kids just wander in regardless, often half-dressed, which makes for some pretty funny meetings ;)

So, I thought it would be neat to create a little application that could show "On-Air" or similar when parked on a small monitor (think a USB MIMO display) facing towards the door. When I build my new office in the next room, I'll actually stick this outside the door so people can see before wandering in.

I haven't purchased the MIMO yet, as I wanted to do a little proof-of-concept project first. The app described in this post is that proof-of-concept.

Project Setup

Start up a new WPF application. I named mine "PeteBrown.CommunicatorDisplay". Next, add a reference to the communicator API.

To integrate with communicator, you'll want to download the Microsoft Office Communicator 2007 SDK. Once installed, you can browse to the DLLs inside the Add Reference dialog for your project.

CommunicatorAPI is the standard API which can be used to interact with communicator, showing dialogs etc. CommunicatorPrivate provides much of the same functionality, but without displaying any UI. Both libraries were installed to c:\Program Files(x86)\Microsoft Office Communicator\SDK

Working with the API - the CommunicatorService Class

For this little app, I'll need to subscribe to an event that will tell me when my status changes. The event, in this case is OnMyStatusChange. To keep the code somewhat cleaner, I decided to package up all the Communicator interaction (of which there is little in this app), including the wiring of OnMyStatusChange, into a single CommunicatorService class.

public enum CommunicatorStatus
{
    Available,
    OnPhone
}

public class CommunicatorService : IDisposable
{
    private Messenger _messenger;

    public CommunicatorService()
    {
        _messenger = new Messenger();
        _messenger.OnMyStatusChange += new DMessengerEvents_OnMyStatusChangeEventHandler(OnMyStatusChange);

        //TODO: Map startup status
    }

    private void OnMyStatusChange(int hr, MISTATUS mMyStatus)
    {
        System.Diagnostics.Debug.WriteLine(mMyStatus.ToString());
        switch (mMyStatus)
        {
            case MISTATUS.MISTATUS_IN_A_CONFERENCE:
            case MISTATUS.MISTATUS_IN_A_MEETING:
            case MISTATUS.MISTATUS_ON_THE_PHONE:
                Status = CommunicatorStatus.OnPhone;
                break;

            case MISTATUS.MISTATUS_ONLINE: 
            case MISTATUS.MISTATUS_OFFLINE:
            case MISTATUS.MISTATUS_AWAY:
                Status = CommunicatorStatus.Available;
                break;

        }
    }

    public event EventHandler StatusChanged;
    private CommunicatorStatus _status;
    public CommunicatorStatus Status
    {
        get { return _status; }
        set
        {
            if (_status != value)
            {
                _status = value;

                if (StatusChanged != null)
                    StatusChanged(this, EventArgs.Empty);
            }
        }
    }

    public void Dispose()
    {
        if (_messenger != null)
        {
            _messenger.OnMyStatusChange -= OnMyStatusChange;
            _messenger = null;
        }
    }

    ~CommunicatorService()
    {
        if (_messenger != null)
            Dispose();
    }
}

Note that I implement IDisposable here. I wanted to clean up the Communicator hooks. It's very likely overkill, but if I end up doing more with this class in the future, I'll be class it's in place.

Once I had the service set up, I create a view model class to act as the glue between the view and the service.

The ViewModel

This application has only a single viewmodel class. That's due to having only a single view. This class is responsible for creating the communicator service instance, and for handling the StatusChanged event. It then takes the information from the service and maps it to a set of bindable properties used by the UI.

public class MainViewModel : Observable
{
    private CommunicatorService _communicatorService;

    public MainViewModel()
    {
        _communicatorService = new CommunicatorService();
        _communicatorService.StatusChanged += new EventHandler(OnCommunicatorStatusChanged);
    }

    void OnCommunicatorStatusChanged(object sender, EventArgs e)
    {
        switch (_communicatorService.Status)
        {
            case CommunicatorStatus.Available:
                StatusText = "Available";
                DoNotDisturb = false;
                break;

            case CommunicatorStatus.OnPhone:
                StatusText = "On the Phone";
                DoNotDisturb = true;
                break;
        }
    }

    private string _statusText = string.Empty;
    public string StatusText
    {
        get { return _statusText; }
        set
        {
            if (_statusText != value)
            {
                _statusText = value;
                NotifyPropertyChanged("StatusText");
            }
        }
    }

    private bool _doNotDisturb = false;
    public bool DoNotDisturb
    {
        get { return _doNotDisturb; }
        set
        {
            if (_doNotDisturb != value)
            {
                _doNotDisturb = value;
                NotifyPropertyChanged("DoNotDisturb");
            }
        }
    }
}

As is my usual approach, I created a simple base class named "Observable" to handle the INotifyPropertyChanged cruft.

public abstract class Observable : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void NotifyPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

The User Interface

The UI is pretty basic. If I'm not to be disturbed, the color is Red. If I'm available, the color is green. In both cases, the status text is displayed in white against this background color.

I handled the display of the red background using the built-in BooleanToVisibilityConverter in WPF in a binding statement against the DoNotDisturb property of the viewmodel. The text displayed comes from the StatusText property of the viewmodel. The green background is always there, but it is revealed only when the red background is collapsed.

The Window is sized fro the typical 800x400 resolution of some of the mini USB displays. Some other displays have different resolutions; adjust as necessary.

The code-behind for the window is pretty brief:

public partial class MainWindow : Window
{
    MainViewModel _vm;

    public MainWindow()
    {
        InitializeComponent();

        Loaded += new RoutedEventHandler(MainWindow_Loaded);
    }

    void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        _vm = new MainViewModel();
        DataContext = _vm;
    }
}

All I do there is instantiate the viewmodel and assign it as the DataContext for the window.

Test Run

To test, I called my mobile phone from communicator. Within a couple seconds, the WPF application picked up and displayed the correct status:

Once I hung up, I got the expected "Available" status. Remember, I don't care if the status is "Away" or anything like that; this is just to tell people whether or not it's ok to wander into the office and ask me a question

That's all there is to it from a proof-of-concept level of application.

Wrap-Up

The Communicator API is simple to use from a WPF application, even without using some of the wrapper WPF presence controls.

Of course, this is a proof-of-concept. To make this more robust, I'll want to add in code to handle disconnection and shutdown, as well as other events. I'll also need to handle other statuses to ensure I have all the types of meetings covered. I'd want to check the status at startup and make sure I have that handled as well. Finally, this whole application could be refactored to use a custom control with visual states for each of the communicator statuses rather than the DoNotDisturb boolean value.

Oh, and plugging in other apps would be nice. For example, if Camtasia is running, it would be nice to automatically set this to stay "Recording" or something like that.

Custom Placement within an ItemsControl in WPF

Pete Brown — Thu, 16 Sep 2010 21:33:11 GMT

I've been tripped up on a problem in Shoebox Scan for several weeks now. I'll pick it up for an hour or two on a Friday, get nowhere, and put it down until later the next week. Today, I finally figured out what the problem is. (Yes, I have been piddling with this application since early this year. I'm pretty sure Scott has a special ulcer just for me and Shoebox scan )

Background

I rewrote Shoebox Scan so I could make the code follow modern WPF coding and design practices. There were some areas of really tight coupling between some of the UI elements and the backing store that were a constant source of churn whenever I made a change. I won't say it was a disaster, but it was a mess. The part of the code had to do with the selection of regions in the image for purposes of rotating and cropping.

Here's a work-in-progress screenshot showing two selection regions on a scanned image. The adorners are turned off for the moment because I thought they were the problem. Without the adorners, you can move the regions around. With the adorners, you can move everything around, plus rotate and resize to select a region from the image to save to a file.

Refactoring

So, I refactored it to use MVVM with binding in the UI. Rather than have these other controls injecting everything via code, I was able to move the UI into XAML. Rather than have code which added and removed regions, I was able to use a plain old ItemsControl to represent them on-screen, and a data template to define the appearance. I'll probably retemplate a listbox or derive my own control from Selector later.

You wouldn't normally think of an ItemsControl in this context. ItemsControls are usually thought of for lists of data in some structured format. This is free form: each item can be a different size, rotation and location.

Inside the data template, I bound the root grid of the template to the Left, Top, Width, and Height of the SelectionRegion.

The Problem

While the ItemsControl is actually perfectly suited to this, The problem I ran into was that no matter what I did, I could not get the regions to move from the top left. I could see that the properties were correct in the viewmodel.

In the DataTemplate, I had set up a root Grid, and bound the Canvas.Left and Canvas.Top properties to the appropriate properties on the SelectionRegion model object. In the debugger, I verified that the properties were being updated, that there were no binding problems. I also did the usual replacement of the ItemsPanel with a canvas set to stretch in both directions. Still no go. Despite the frustration of seeing everything correct in the debugger, the visuals weren't correct.

The Debugging (well, the last bit of it, anyway)

I cracked open Snoop and looked at the tree. It occurred to me that the problem might be with the ContentPresenter's positioning or sizing.

Sure enough, when I looked at the ActualHeight and ActualWidth, I saw that the content presenter was sized to the individual item. This seems obvious in retrospect, but it took a while to find it.

The Solution

The solution, of course, was to set the ItemContainerStyle and bind that to the Left, Top, Width and Height. The resulting ItemsControl with the appropriate templates, looks like this:

I'm posting this in case someone else tries to bend an ItemsControl in a similar way, and runs into problems with positioning. Now I can go back to solving the hard problems around rotation and cropping :)