WPF Mentor

How to use the controls from NavigationWindow in your own Window

2009-02-09T17:53:00.003Z

I've made a control containing back and forward buttons and a history menu in the style of IE 7. The XAML has been lifted directly from the WPF NavigationWindow template and converted to a control so it can be used in the normal way.

Here's a screenshot of the controls I am talking about (magnified 2x here):

These are the step I went through to do this:

A new Custom Control was created named NavigationControl. This was changed to derive from System.Windows.Controls.Selector as the control will contain a list of items of which one can be selected.
The BAML Viewer plugin for Reflector was used to extract the default style for the Navigation Window. The template XAML was copied and pasted to the template for NavigationControl.
The various components were extracted out into separate resource dictionaries for the different components to aid readability.
The button XAML was repeated for the two buttons. This was converted into one and a trigger was added to switch between the two.
A class called ThemedResourceDictionarySelector was created to assist in defining the themed parts of the template. This meant that the entire template did not need to be repeated for each theme.
Code behind was added so that the menu was correctly populated when the items of NavigationControl changed.

Download source code

How to recreate the Microsoft Office Access welcome page in XAML

2009-01-30T17:06:00.008Z

I've recreated the Microsoft Office Access welcome/home page using XAML.

This is the kind of thing that WPF is so great for...and is a complete nightmare to do in WinForms. You can download the source using the link at the bottom of the post.

Click here for the full screen shot.

Download source code

How to add custom data to an AutomationPeer

2009-01-28T14:33:00.005Z

In a recent project, we needed to provide extra data through Automation in order to achieve more rigorous testing. We wanted some of our own properties and data types unrelated to the available control patterns and properties.

After spending some time searching for a mechanism to add new properties we came to the conclusion that there wasn't one - the only choice is to hijack an existing property. As far as I can tell the only automation property you're allowed to put whatever you want in is ItemStatus.

The MSDN page for ItemStatus says:

Gets or sets a description of the status of an item within an element.
This property enables a client to ascertain whether an element is conveying status about an item. For example, an item associated with a contact in a messaging application might be "Busy" or "Connected".

That sounds pretty hijackable to me.

ItemStatus is hidden by default in UISpy but you can show it by going to:
View -> Configure Properties -> AutomationElement -> Misc

You set it in your automation peer by overriding GetItemStatusCore(). You can then serialize any type and send it through:

public class Window1AutomationPeer : WindowAutomationPeer
{
    public Window1AutomationPeer(Window1 owner)
        : base(owner)
    {
    }

    protected override string GetItemStatusCore()
    {
        // use XmlSerializer to serialize custom data
        
        XmlSerializer serializer = new XmlSerializer(typeof(CustomData));
        CustomData data = new CustomData(...);
        StringWriter stringWriter = new StringWriter(CultureInfo.InvariantCulture);
        serializer.Serialize(stringWriter, data);
        return stringWriter.ToString();
    }
}

The example contains a working example complete with app, automation-client and XML serialization.

How to find out what that XamlParseException really means using MarkupSource tracing

2009-01-27T17:00:00.002Z

It's sometimes pretty difficult to work out what the XamlParseException thrown when your app starts really means. WPF Markup tracing logs everything in the output window as the XAML is loaded - this nearly always gets you to the source of the problem.

You can turn it on like this:

public Window1()
{
    PresentationTraceSources.Refresh();
    PresentationTraceSources.MarkupSource.Switch.Level = SourceLevels.All;
    PresentationTraceSources.MarkupSource.Listeners.Add(new DefaultTraceListener());
    ...
}

How to add a binding to the CommandParameter of a KeyBinding or MouseBinding

2009-01-27T15:04:00.007Z

You can't add a binding to the command parameter of an InputBinding. Although InputBinding does derive from DependencyObject, the CommandParameter property is a CLR property. It was implemented in this way as InputBindings don't sit in an inheritance context and so normal bindings are not supported.

Fortunately, this can be worked around in the same way as in my previous post:

<Window.Resources>
    <my:DataResource x:Key="cp" BindingTarget="{Binding MyCommandParameter}"/>
</Window.Resources>
<TextBox>
    <TextBox.InputBindings>
        <MouseBinding 
            Command="ApplicationCommands.Open" 
            MouseAction="LeftDoubleClick">
            <MouseBinding.CommandParameter>
                <my:DataResourceBinding DataResource="{StaticResource cp}"/>
            </MouseBinding.CommandParameter>
        </MouseBinding>
    </TextBox.InputBindings>
</TextBox>

DataResource.cs
Download sample app with source code

How to add a binding to a property on a ValidationRule

2009-01-27T14:39:00.004Z

You can't add bindings to properties on classes that derive from ValidationRule in the normal way. This is because validation rules don't sit in an inheritance context and don't derive from DependencyObject.

Fortunately, this can easily be worked around using the DataResource technique from a previous post. Here's how you would use this technique for max/min integer validation.

First create the rule class:

public class IntValidationRule : ValidationRule
{
    public int Max { get; set; }
    public int Min { get; set; }

    public override ValidationResult Validate(object value, CultureInfo cultureInfo)
    {
        try
        {
            int i = Convert.ToInt32(value);
            return (i < Min || i > Max) ?
                new ValidationResult(false, "int out of range") :
                new ValidationResult(true, null);
        }
        catch (FormatException fe)
        {
            return new ValidationResult(false, fe.Message);
        }
    }
}

...the DataResources and the associated bindings should then simply be set up like this:

<Window.Resources>
    <my:DataResource x:Key="max" BindingTarget="{Binding Max}"/>
    <my:DataResource x:Key="min" BindingTarget="{Binding Min}"/>
</Window.Resources>

<TextBox>
    <TextBox.Text>
        <Binding UpdateSourceTrigger="PropertyChanged" Path="Value">
            <Binding.ValidationRules>
                <my:IntValidationRule 
                    ValidatesOnTargetUpdated="True" 
                    Min="{my:DataResourceBinding DataResource={StaticResource min}}"
                    Max="{my:DataResourceBinding DataResource={StaticResource max}}">
                </my:IntValidationRule>
            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>

DataResource.cs
Download sample app with source code

How to get the HWND and hook into the WndProc of a WPF application

2009-01-23T18:51:00.002Z

I've written a quick sample which hooks into the WM_ messages and displays them real-time. It looks like this:

This is the code that does the work:


private void Window1_Loaded(object sender, RoutedEventArgs e)
{
    // do this to get the HWND and set up the window hook
    WindowInteropHelper helper = new WindowInteropHelper(this);
    HwndSource.FromHwnd(helper.Handle).AddHook(HwndSourceHookHandler);
}

private IntPtr HwndSourceHookHandler(IntPtr hwnd, int msg, IntPtr wParam, 
    IntPtr lParam, ref bool handled)
{
    // this is the window hook handler
}

Download sample app with source code

How to debug triggers using Trigger-Tracing

2009-01-22T18:05:00.007Z

Debugging triggers is a painful process: they work behind the scenes, there's nowhere to put a breakpoint and no call-stack to help you. The usual approach taken is trial and error based and it nearly always takes longer than it should to work out what's going wrong.

This post describes a new technique for debugging triggers allowing you to log all trigger actions along with the elements being acted upon:

It's good because it:

helps you fix all manner of problems :)
works on all types of trigger: Trigger, DataTrigger, MultiTrigger etc.
allows you to add breakpoints when any trigger is entered and/or exited

is easy to set up: just drop one source file (TriggerTracing.cs) into your app and set these attached properties to the trigger to be traced:

<Trigger my:TriggerTracing.TriggerName="BoldWhenMouseIsOver"
         my:TriggerTracing.TraceEnabled="True"
         Property="IsMouseOver"
         Value="True">
    <Setter Property="FontWeight" Value="Bold"/>
</Trigger>

It works by:

using attached properties to add dummy animation storyboards to the trigger
activating WPF animation tracing and filtering the results to only the entries with the dummy storyboards

Download sample app with source code

How to transfer rich text from a FlowDocument to a FormattedText object

2009-01-16T15:25:00.003Z

The FormattedText class provides low-level control for drawing text. It gives you high performance multi-line text rendering in which each character in the text can be individually formatted.

Other aspects of text in WPF handle text in the context of controls that are dedicated to text (TextBlock, TextBox, RichTextBox), implement the FlowDocument model. As far as I can tell, there is no direct way to transfer text from a FlowDocument to a FormattedText object. This post outlines how it can be done with a bit of jiggery poker.

The tricky part of this process is traversing through the runs and paragraphs in the FlowDocument:

private IEnumerable<TextElement> GetRunsAndParagraphs(FlowDocument doc)
{
    // use the GetNextContextPosition method to iterate through the
    // FlowDocument
    
    for (TextPointer position = doc.ContentStart;
        position != null && position.CompareTo(doc.ContentEnd) <= 0;
        position = position.GetNextContextPosition(LogicalDirection.Forward))
    {
        if (position.GetPointerContext(LogicalDirection.Forward) == 
            TextPointerContext.ElementEnd)
        {
            // return solely the Runs and Paragraphs. all other elements are 
            // ignored since they aren't supported by FormattedText.
            
            Run run = position.Parent as Run;

            if (run != null)
            {
                yield return run;
            }
            else
            {
                Paragraph para = position.Parent as Paragraph;

                if (para != null)
                {
                    yield return para;
                }
            }
        }
    }
}

The rest of process is fairly straightforward. Use the GetRunsAndParagraphs method and build up the formatting on a FormattedText object:

public FormattedText GetFormattedText(FlowDocument doc)
{
    if (doc == null)
    {
        throw new ArgumentNullException("doc");
    }

    FormattedText output = new FormattedText(
        GetText(doc),
        CultureInfo.CurrentCulture,
        doc.FlowDirection,
        new Typeface(doc.FontFamily, doc.FontStyle, doc.FontWeight, doc.FontStretch),
        doc.FontSize,
        doc.Foreground);

    int offset = 0;

    foreach (TextElement el in GetRunsAndParagraphs(doc))
    {
        Run run = el as Run;

        if (run != null)
        {
            int count = run.Text.Length;

            output.SetFontFamily(run.FontFamily, offset, count);
            output.SetFontStyle(run.FontStyle, offset, count);
            output.SetFontWeight(run.FontWeight, offset, count);
            output.SetFontSize(run.FontSize, offset, count);
            output.SetForegroundBrush(run.Foreground, offset, count);
            output.SetFontStretch(run.FontStretch, offset, count);
            output.SetTextDecorations(run.TextDecorations, offset, count);

            offset += count;
        }
        else
        {
            offset += Environment.NewLine.Length;
        }
    }

    return output;
}

private string GetText(FlowDocument doc)
{
    StringBuilder sb = new StringBuilder();

    foreach (TextElement el in GetRunsAndParagraphs(doc))
    {
        Run run = el as Run;
        sb.Append(run == null ? Environment.NewLine : run.Text);
    }
    return sb.ToString();
}

You can download the source code and demo here.

How to ensure a new instance of a resource is returned every time it is requested

2009-01-15T13:00:00.000Z

There's a little known attribute named x:Shared for this purpose. It's little known since it doesn't appear in Intellisense for some reason. Add the attribute it to any item in a resource dictionary and set its value to False to ensure each request returns a new instance.

The value of the attribute is True by default. This means that any given resource request always returns the same instance by default.

This code snippet demonstrates its usage:

<Window.Resources>
    <ContextMenu x:Shared="False" x:Key="menu">
        <ContextMenu.Items>
            <MenuItem Header="A Menu Item"/>
        </ContextMenu.Items>
    </ContextMenu>
</Window.Resources>

<StackPanel>
    <Button Content="Button1" ContextMenu="{StaticResource menu}" Click="Btn_Click"/>
    <Button Content="Button2" ContextMenu="{StaticResource menu}" Click="Btn_Click"/>
</StackPanel>

private void Btn_Click(object sender, RoutedEventArgs e)
{
    Button b = (Button)sender;
    MenuItem item = (MenuItem)b.ContextMenu.Items[0];
    item.IsChecked = !item.IsChecked;
}

Visit the MSDN page for more info about this attribute.

How to intercept a copy or paste operation

2009-01-13T15:19:00.002Z

I've just found these static methods on the System.Windows.DataObject class.

DataObject.AddPastingHandler(dependencyObject, handler);
DataObject.RemovePastingHandler(dependencyObject, handler);

DataObject.AddCopyingHandler(dependencyObject, handler);
DataObject.RemovePastingHandler(dependencyObject, handler);

DataObject.AddSettingDataHandler(dependencyObject, handler);
DataObject.RemoveSettingDataHandler(dependencyObject, handler);

Very useful!!

You can use these to inspect an object before it is pasted/copied/drag-dropped and change the course of the action by doing stuff like Cancel or Change Format.

How to assign a URL to one or more CLR namespaces

2009-01-12T19:44:00.009Z

Look at the way the XML namespaces are defined in the snippet below. The 'local' definition is mapped directly to a CLR namespace in the normal way but the first two definitions are just URLs. What do thes URLs represent and where are they defined?

<Window x:Class="WpfLibrary.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WpfLibrary">
    
    <Window.Resources>
        <SolidColorBrush Color="AliceBlue"/>
    </Window.Resources>
    
    <TextBox/>
    
    
    
</Window>

The URLs have been setup to represent multiple CLR namespaces in the AssemblyInfo of the assembly in which they are defined. Notice that both the TextBox and SolidColorBrush classes are referenced using the default XML namespace even though the classes are actually defined in different CLR namespaces.

To find out which CLR namespaces are assigned to a particular URL then you can look at the assembly definition in Reflector.

Here's the syntax to set this up in the AssemblyInfo of your assembly:

[assembly:XmlnsDefinition("http://myorganization.com", "WpfLibrary")]
[assembly:XmlnsDefinition("http://myorganization.com", "WpfLibrary.Pens")]
[assembly:XmlnsDefinition("http://myorganization.com", "WpfLibrary.Brushes")]

Consumers of your assembly can then use the XML namespace to reference all of the associated CLR namespaces in one swoop:

<Window x:Class="WpfApplication1.Window1"
 xmlns:myorg="http://myorganization.com"
</Window>

How to make the text of a CheckBox wrap across multiple lines

2009-01-10T15:54:00.000Z

Just a quick one about how to make CheckBox text wrap across multiple lines while showing text accelerators correctly.

You might have noticed that a CheckBox doesn't have properties like TextWrapping and TextTrimming. This is because CheckBox derives from ContentControl and can therefore take any element as its content - it doesn't have to be a string like in the bad old WinForms days.

In order to add text wrapping, you could add a TextBlock to the Content of the CheckBox like this:

<CheckBox>
    <TextBlock TextWrapping="Wrap"
        Text="_This is a long piece of text attached to a checkbox."/>
</CheckBox>

There is a problem regarding accelerator keys here though. Look at the output from the last example:

...the accelerator isn't display correctly. TextBlocks don't support accelerator keys. In order to do this properly you should use an AccessText element to display your text:

<CheckBox>
    <AccessText TextWrapping="Wrap"
        Text="_This is a long piece of text attached to a checkbox."/>
</CheckBox>

This will ensure that the underscore is correctly displayed.

How to sort a BindingList using CollectionViewSource

2008-12-12T15:05:00.008Z

If you've ever tried to sort a BindingList (or any other collection implementing IBindingList) using CollectionViewSource then you've most probably not had much luck. The BindingListCollectionView used for this task lacks the functionality of ListCollectionView and on top of that has a bug making it even more onerous to use. This post describes a workaround so you can use ListCollectionView instead.

BindingListCollectionView unfortunately doesn't have the sorting capabilities of ListCollectionView. It only uses the in-built sorting defined in IBindingList instead of doing it itself and if that's not enabled it will throw an exception. Not very useful.

On top of that, if your BindingList doesn't implement ITypedList then the sorting fails silently even if you have implemented the sorting!

Here's a nice trick to adapt a BindingList to an ObservableCollection and therefore make the CollectionViewSource use the ListCollectionView implementation for sorting:

class ExtendedCollectionViewSource : CollectionViewSource
{
    private BindingListAdapter mAdapter;

    static ExtendedCollectionViewSource()
    {
        CollectionViewSource.SourceProperty.OverrideMetadata(
            typeof(ExtendedCollectionViewSource),
            new FrameworkPropertyMetadata(null, CoerceSource));
    }

    private static object CoerceSource(DependencyObject d, object baseValue)
    {
        ExtendedCollectionViewSource cvs = (ExtendedCollectionViewSource)d;
        if (cvs.mAdapter != null)
        {
            cvs.mAdapter.Dispose();
            cvs.mAdapter = null;
        }
        IBindingList bindingList = baseValue as IBindingList;
        if (bindingList != null)
        {
            cvs.mAdapter = new BindingListAdapter(bindingList);
            return cvs.mAdapter;
        }
        return baseValue;
    }
}

private class BindingListAdapter : ObservableCollection<object>, IDisposable
{
    private readonly IBindingList mBindingList;
    private bool mIsDisposed;

    public BindingListAdapter(IBindingList bindingList)
    {
        if (bindingList == null)
        {
            throw new ArgumentNullException("bindingList");
        }

        mBindingList = bindingList;

        foreach (object item in mBindingList)
        {
            Items.Add(item);
        }

        mBindingList.ListChanged += BindingList_ListChanged;
    }

    private void BindingList_ListChanged(object sender, ListChangedEventArgs e)
    {
        if (e.ListChangedType == ListChangedType.ItemAdded)
        {
            InsertItem(e.NewIndex, mBindingList[e.NewIndex]);
        }
        else if (e.ListChangedType == ListChangedType.ItemChanged)
        {
            SetItem(e.NewIndex, mBindingList[e.NewIndex]);
        }
        else if (e.ListChangedType == ListChangedType.ItemDeleted)
        {
            RemoveItem(e.NewIndex);
        }
        else if (e.ListChangedType == ListChangedType.ItemMoved)
        {
            MoveItem(e.OldIndex, e.NewIndex);
        }
        else if (e.ListChangedType == ListChangedType.Reset)
        {
            Items.Clear();

            foreach (object item in mBindingList)
            {
                Items.Add(item);
            }
            
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Reset));
        }
    }

    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!mIsDisposed)
        {
            if (disposing)
            {
                mBindingList.ListChanged -= BindingList_ListChanged;
            }
        }
        mIsDisposed = true;
    }

    #endregion
}

ExtendedCollectionViewSource.cs

How to set the size and position of a scroll bar thumb

2008-12-11T16:23:00.010Z

The WPF scrollbars seem to be unduly difficult to use. This post describes why and defines some extension methods to make life a little easier.

The ScrollBar class has these properties to specify the thumb location and the thumb size:

Value - represents the thumb position
ViewportSize - represents the thumb location

Value varies between Maximum and Minimum. So if Maximum=100, Minimum=0 and Value=50. Then the thumb is in the middle, this is definitely the more sensible of the two properties. However, it's not great: it doesn't directly represent the absolute position of the thumb on the track.

ViewportSize varies between 0 and double.MaxValue. What!? What use is this to anyone?

What you nearly always have when you are implementing your own scrolling is the length of the thumb and the absolute position of the thumb. Here are some extension methods that convert these to and from the WPF properties.

public static class ScrollBarExtensions
{
    public static double GetThumbCenter(this ScrollBar s)
    {
        double thumbLength = GetThumbLength(s);
        double trackLength = s.Maximum - s.Minimum;        

        return thumbLength / 2 + s.Minimum + (s.Value - s.Minimum) * 
            (trackLength - thumbLength) / trackLength;
    }

    public static void SetThumbCenter(this ScrollBar s, double thumbCenter)
    {
        double thumbLength = GetThumbLength(s);
        double trackLength = s.Maximum - s.Minimum;

        if (thumbCenter >= s.Maximum - thumbLength / 2)
        {
            s.Value = s.Maximum;
        }
        else if (thumbCenter <= s.Minimum + thumbLength / 2)
        {
            s.Value = s.Minimum;
        }
        else if (thumbLength >= trackLength )
        {
            s.Value = s.Minimum;
        }
        else
        {
            s.Value = s.Minimum + trackLength  * 
                ((thumbCenter - s.Minimum - thumbLength / 2) 
                / (trackLength - thumbLength));
        }
    }

    public static double GetThumbLength(this ScrollBar s)
    {
        double trackLength = s.Maximum - s.Minimum;
        return trackLength * s.ViewportSize / 
            (trackLength + s.ViewportSize);
    }

    public static void SetThumbLength(this ScrollBar s, double thumbLength)
    {
        double trackLength = s.Maximum - s.Minimum;

        if (thumbLength < 0)
        {
            s.ViewportSize = 0;
        }
        else if (thumbLength < trackLength )
        {
            s.ViewportSize = trackLength * thumbLength / (trackLength - thumbLength);
        }
        else
        {
            s.ViewportSize = double.MaxValue;
        }
    }
}

ScrollBarExtensions.cs

Observable collections independent of WPF

2008-12-11T10:28:00.011Z

I've recently been working with a client who has made the decision to keep the business logic assembly of their WPF application independent of WPF. This is fair enough, keeping the business logic separate from the presentation code and independent of WPF will promote decoupled design and reduce the pain down the line if the business logic needs to be transplanted elsewhere.

The client had the further requirement that the collections within the businsess logic should be observable by WPF in order to avoid the overhead of creating an entire View-Model layer to support the UI. Even though I'm unsure as to whether there's anyone else out there being so strict about their dependencies, implementing this turns out to be less straightforward than you'd expect, so I thought I'd write a post about it anyway.

First of all, here's a quick reminder of the interfaces that WPF data binding generally uses to observe the contents of a collection:

IList - used to traverse the items in a collection.
INotifyPropertyChanged - used to inform listeners that the value of a property of a collection has changed i.e. the count and the indexer properties.
INotifyCollectionChanged - used to inform listeners that a collection has changed in some way e.g. an item has been added, removed, moved etc.

The problem here is that INotifyCollectionChanged is part of WPF as it is defined in WindowsBase and therefore can't be used in the proposed structure. An alternative to using INotifyCollectionChanged is to use the somewhat older interface, System.ComponentModel.IBindingList, which has been around since .NET 1.0 supporting data binding in Windows Forms. IBindingList is also supported by WPF data binding and this post focuses on it as an alternative to INotifyCollectionChanged thus removing the dependency on WPF.

As well as change notification, IBindingList contains functionality for Adding, Removing, Sorting and Searching (it's a bit of a bizarre interface really, containing all this different functionality). In this implementation, sorting will be disabled since it was desired that it is handled in the view as it is for collections implementating INotifyCollectionChanged. Adding, removing and searching can all be implemented as you see fit but in this example I will be disabling them.

Implementing IBindingList is straightforward enough. If you were to implement it on your collection, it should end up looking something like this:

class MyObservableCollection<T> : Collection<T>, IBindingList
{
    protected override void ClearItems()
    {
        base.ClearItems();
        OnListChanged(new ListChangedEventArgs(ListChangedType.Reset), -1);
    }

    protected override void InsertItem(int index, T item)
    {
        base.InsertItem(index, item);
        OnListChanged(new ListChangedEventArgs(ListChangedType.ItemAdded, index));
    }

    protected override void RemoveItem(int index)
    {
        base.RemoveItem(index);
        OnListChanged(new ListChangedEventArgs(ListChangedType.ItemDeleted, index));
    }

    protected override void SetItem(int index, T item)
    {
        base.SetItem(index, item);
        OnListChanged(new ListChangedEventArgs(ListChangedType.ItemChanged, index));
    }

    protected virtual void OnListChanged(ListChangedEventArgs e)
    {
        var handler = ListChanged;
        if (handler != null) handler(this, e);
    }

    // IBindingList Members 
    public void AddIndex(PropertyDescriptor property) {}
    public object AddNew() {}
    public void ApplySort(PropertyDescriptor property, ListSortDirection direction) {}
    public int Find(PropertyDescriptor property, object key) {}
    public void RemoveIndex(PropertyDescriptor property) {}
    public void RemoveSort() {}
    public event ListChangedEventHandler ListChanged;
    public bool SupportsChangeNotification { get { return true; } } // Must return true
    public bool AllowEdit { get { return false; } }
    public bool AllowNew { get { return false; } }
    public bool AllowRemove { get { return false; } }
    public bool IsSorted { get { return false; } }
    public ListSortDirection SortDirection
    { get { throw new NotSupportedException(); } }
    public PropertyDescriptor SortProperty
    { get { throw new NotSupportedException(); } }
    public bool SupportsChangeNotification { get { return true; } }
    public bool SupportsSearching { get { return false; } }
    public bool SupportsSorting { get { return false; } }
}

So far, so good. We now have a collection that implements IBindingList and can therefore be used for data binding. So let's try it by binding a ListBox to the new collection:

<Window ...>
    <StackPanel>
        <Button Content="Add" Click="ButtonAdd_Click"/>
        <ListBox ItemsSource="{Binding}"/>
    </StackPanel>
</Window>

public partial class Window1 : Window
{
    private readonly MyObservableCollection<int> mCollection;
    private int mCounter;

    public Window1()
    {
        InitializeComponent();
        mCollection = new MyObservableCollection<int>();
        DataContext = mCollection;
    }

    private void ButtonAdd_Click(object sender, RoutedEventArgs e)
    {
        mCollection.Add(mCounter++);
    }
}

It works! You can click on the Add button and the listbox correctly updates. Now let's try sorting a view of the collection using a CollectionViewSource:

<Window ...>
    <Window.Resources>
        <CollectionViewSource x:Key="cvs" Source="{Binding}">
            <CollectionViewSource.SortDescriptions>
                <compModel:SortDescription Direction="Descending"/>
            </CollectionViewSource.SortDescriptions>
        </CollectionViewSource>
    </Window.Resources>
    <StackPanel>
        <Button Content="Add" Click="ButtonAdd_Click"/>
        <ListBox ItemsSource="{Binding Source={StaticResource cvs}}"/>
    </StackPanel>
</Window>

Hmmm...this isn't nearly so successful. The window now throws an exception on startup:

InvalidOperationException: 'System.Windows.Data.BindingListCollectionView' view does not support sorting.

This is because the BindingListCollectionView, the implementation of ICollectionView created by the CollectionViewSource for viewing collections implementing IBindingList is using the internal sorting mechanism provided by the IBindingList interface. Since SupportsSorting is set to false, an exception now gets thrown when an attempt is made to sort the collection. SupportsSorting can't be set to true as then sorting would have to actually be implemented by the collection and the requirement is for it to be handled in the view as it is for collections implementing INotifyCollectionChanged.

This poses a bit of a problem. Luckily, we have a dirty workaround to rememdy the situation.

CollectionViewSource can be subclassed and its Source property coerced into using an adapted version of original collection which implements INotifyCollectionChanged. This adapter maps the change events from the IBindingList interface to the equivalents on the INotifyCollectionChanged interface.

But...there's another problem. There isn't enough information from IBindingList's ListChangedEventArgs to fully populate INotifyCollectionChanged's NotifyCollectionChangedEventArgs. So we'll also need to subclass the ListChangedEventArgs class before raising the change events from the collection.

Here's a rundown of all the bits that are required. Firstly, here's the new CollectionViewSource which coerces an instance of the new BindingListAdapter class when its Source property gets set:

class ExtendedCollectionViewSource : CollectionViewSource
{
    private BindingListAdapter mAdapter;

    static ExtendedCollectionViewSource()
    {
        CollectionViewSource.SourceProperty.OverrideMetadata(
            typeof(ExtendedCollectionViewSource),
            new FrameworkPropertyMetadata(null, CoerceSource));
    }

    // This class should be kept internal as the Coerce is a little dodgy. 
    // Consumers of this class could reasonably expect the Source property
    // to return the same instance that was set to it.
    
    private static object CoerceSource(DependencyObject d, object baseValue)
    {
        ExtendedCollectionViewSource cvs = (ExtendedCollectionViewSource)d;
        if (cvs.mAdapter != null)
        {
            cvs.mAdapter.Dispose();
            cvs.mAdapter = null;
        }
        IBindingList bindingList = baseValue as IBindingList;
        if (bindingList != null)
        {
            cvs.mAdapter = new BindingListAdapter(bindingList);
            return cvs.mAdapter;
        }
        return baseValue;
    }
}

Next, the BindingListAdapter class, which adapts a class implementing IBindingList into one which implements INotifyCollectionChanged.

class BindingListAdapter : IList, IDisposable, INotifyPropertyChanged, 
    INotifyCollectionChanged
{
    private readonly IBindingList mBindingList;

    public BindingListAdapter(IBindingList bindingList)
    {
        mBindingList = bindingList;
        mBindingList.ListChanged += mBindingList_ListChanged;
    }

    private void mBindingList_ListChanged(object sender, ListChangedEventArgs e)
    {
        ExtendedListChangedEventArgs ee = (ExtendedListChangedEventArgs)e;
        
        if (e.ListChangedType == ListChangedType.ItemAdded)
        {
            OnPropertyChanged(new PropertyChangedEventArgs("Count"));
            OnPropertyChanged(new PropertyChangedEventArgs("Item[]"));
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Add, mBindingList[e.NewIndex],
                e.NewIndex));
        }
        else if (e.ListChangedType == ListChangedType.ItemChanged)
        {
            OnPropertyChanged(new PropertyChangedEventArgs("Item[]"));
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Replace, mBindingList[e.NewIndex],
                ee.Item));
        }
        else if (e.ListChangedType == ListChangedType.ItemDeleted)
        {
            OnPropertyChanged(new PropertyChangedEventArgs("Count"));
            OnPropertyChanged(new PropertyChangedEventArgs("Item[]"));
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Remove, ee.Item, e.NewIndex));
        }
        else if (e.ListChangedType == ListChangedType.ItemMoved)
        {
            OnPropertyChanged(new PropertyChangedEventArgs("Item[]"));
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Move, ee.Item, e.NewIndex, e.OldIndex));
        }
        else if (e.ListChangedType == ListChangedType.Reset)
        {
            OnPropertyChanged(new PropertyChangedEventArgs("Count"));
            OnPropertyChanged(new PropertyChangedEventArgs("Item[]"));
            OnCollectionChanged(new NotifyCollectionChangedEventArgs(
                NotifyCollectionChangedAction.Reset, null, -1));
        }
    }
    
    protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        var handler = PropertyChanged;
        if (handler != null) handler(this, e);
    }
    
    protected virtual void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        var handler = CollectionChanged;
        if (handler != null) handler(this, e);
    }

    // I've excluded the implementation of these interfaces here. 
    // Source code is available at the foot of the post.
    
    // IList Members
    // ICollection Members
    // IEnumerable Members
    // INotifyPropertyChanged Members
    // INotifyCollectionChanged Members
    // IDisposable
}

...and the ExtendedListChangedEventArgs class which contains extra information required to populate the INotifyCollectionChangedEventArgs.

class ExtendedListChangedEventArgs : ListChangedEventArgs
{
    public object Item { get; private set; }

    public ExtendedListChangedEventArgs(ListChangedType listChangedType, object item, 
        int newIndex) : base(listChangedType, newIndex)
    {
        Item = item;
    }

    public ExtendedListChangedEventArgs(ListChangedType listChangedType, object item, 
        int newIndex, int oldIndex) : base(listChangedType, newIndex, oldIndex)
    {
        Item = item;
    }
}

...and finally, the original collection, updated to use ExtendedListChangedEventArgs:

class MyObservableCollection<T> : Collection<T>, IBindingList
{
    protected override void ClearItems()
    {
        base.ClearItems();
        OnListChanged(
            new ExtendedListChangedEventArgs(ListChangedType.Reset, null, -1));
    }

    protected override void InsertItem(int index, T item)
    {
        base.InsertItem(index, item);
        OnListChanged(
            new ExtendedListChangedEventArgs(ListChangedType.ItemAdded, item, index));
    }

    protected override void RemoveItem(int index)
    {
        T item = base[index];
        base.RemoveItem(index);
        OnListChanged(new ExtendedListChangedEventArgs(
            ListChangedType.ItemDeleted, item, index));
    }

    protected override void SetItem(int index, T item)
    {
        T oldItem = base[index];
        base.SetItem(index, item);
        OnListChanged(new ExtendedListChangedEventArgs(
            ListChangedType.ItemChanged, oldItem, index));
    }

    protected virtual void OnListChanged(ListChangedEventArgs e)
    {
        var handler = ListChanged;
        if (handler != null) handler(this, e);
    }

    // IBindingList Members (not shown here)
}

...and that (believe it or not) actually works. The ExtendedCollectionViewSource successfully coerces the collection into an adapted version of the original before passing it on to CollectionViewSource. The sorting is now entirely handled in the view as it is for collections implementing INotifyCollectionChanged.

As far as I know this approach has no disadvantages to using INotifyCollectionChanged (except that you have to write all of this rhubarb to make it work of course.)

Download Full Source Code

Setting the Context Menu on an editable ComboBox

2008-12-01T17:05:00.014Z

There's a bug in the .NET 3.5 SP1 ComboBox template which stops you setting the context menu on the TextBox part of an editable ComboBox using a Style. This post describes the problem and outlines two workarounds.

This code snippet recreates the issue:

<Window.Resources>
    <ContextMenu x:Key="contextMenu">
        <ContextMenu.Items>
            <MenuItem Header="A Menu Item"/>
        </ContextMenu.Items>
    </ContextMenu>

    <Style TargetType="{x:Type TextBox}">
        <Setter Property="ContextMenu" Value="{StaticResource contextMenu}"/>
    </Style>

    <Style TargetType="{x:Type ComboBox}">
        <Setter Property="ContextMenu" Value="{StaticResource contextMenu}"/>
    </Style>
</Window.Resources>

<ComboBox IsEditable="True"/>

The context menu on the button part of the ComboBox gets set correctly, but the TextBox part is left with its default context menu:

The reason for this is that there is a missing TemplateBinding between the ComboBox and the contained TextBox in the default template. The TextBox style in the code snippet also fails to set the context menu; this is because the ComboBox itself internally sets a style to the TextBox, and it not permissable to have two different styles set to any one instance of a FrameworkElement.

The first workaround to the problem is to subclass the ComboBox and add the required template binding:

class ExtendedComboBox : ComboBox
{
    public override void OnApplyTemplate()
    {
        base.OnApplyTemplate();
        
        // Use Snoop to find the name of the TextBox part
        // http://wpfmentor.blogspot.com/2008/11/understand-bubbling-and-tunnelling-in-5.html
        TextBox textBox = (TextBox)Template.FindName("PART_EditableTextBox", this);
        
        // Create a template-binding in code
        Binding binding = new Binding("ContextMenu");
        binding.RelativeSource = new RelativeSource(RelativeSourceMode.TemplatedParent);
        BindingOperations.SetBinding(textBox, 
            FrameworkElement.ContextMenuProperty, binding);
        
    }
}

This approach does the job. The TextBox's ContextMenu property is now bound to the parent ComboBox and displays correctly.

The obvious problem with this approach is that all the ComboBoxes that require the new context menu now need to be replaced with this new class. This might well not be acceptable, perhaps the ComboBox has been subclassed already - you would need to create new versions for those too.

This second workaround avoids subclassing by using an Attached Behavior. If you are unfamiliar with the Attached Behavior pattern, go here for a great article by Josh Smith.

The Attached Behavior uses an Attached Property which can be set by a Style to create the Template Binding.
In order to create this, first write a new static class with an attached property thus:

public static class ComboBoxContextMenuBehavior
{
    public static bool GetIsContextMenuBound(DependencyObject obj)
    {
        return (bool)obj.GetValue(IsContextMenuBoundProperty);
    }

    public static void SetIsContextMenuBound(DependencyObject obj, bool value)
    {
        obj.SetValue(IsContextMenuBoundProperty, value);
    }

    public static readonly DependencyProperty IsContextMenuBoundProperty =
        DependencyProperty.RegisterAttached(
        "IsContextMenuBound",
        typeof(bool),
        typeof(ComboBoxContextMenuBehavior),
        new UIPropertyMetadata(false, IsContextMenuBoundChanged));
)]

...and add a method to handle changes in the attached property value:

private static void IsContextMenuBoundChanged(DependencyObject d, 
    DependencyPropertyChangedEventArgs e)
{
    ComboBox comboBox = d as ComboBox;

    bool oldValue = e.OldValue is bool && (bool)e.OldValue;
    bool newValue = e.NewValue is bool && (bool)e.NewValue;

    if (comboBox != null && oldValue != newValue)
    {
        // Use Dispatcher with Loaded priority to ensure template has been
        // applied before applying the TemplateBinding
        comboBox.Dispatcher.BeginInvoke(DispatcherPriority.Loaded, 
            (DispatcherOperationCallback)delegate
        {
            TextBox textBox = (TextBox)comboBox.Template.FindName(
                "PART_EditableTextBox", comboBox);

            if (textBox != null)
            {
                if (!oldValue && newValue)
                {
                    // Create TemplateBinding
                    Binding binding = new Binding("ContextMenu");
                    
                    binding.RelativeSource = new RelativeSource(
                        RelativeSourceMode.TemplatedParent);
                    
                    BindingOperations.SetBinding(textBox, 
                        FrameworkElement.ContextMenuProperty, 
                        binding);
                }
                else
                {
                    // Clear TemplateBinding
                    BindingOperations.ClearBinding(textBox, 
                        FrameworkElement.ContextMenuProperty);
                }
            }
            
            return null;
        }, null);
    }
}

The Attached Behavior can now be assigned to the ComboBox using a Style:

<Window.Resources>
    <ContextMenu x:Key="contextMenu">
        <ContextMenu.Items>
            <MenuItem Header="A Menu Item"/>
        </ContextMenu.Items>
    </ContextMenu>

    <Style TargetType="{x:Type ComboBox}">
        <Setter Property="ContextMenu" Value="{StaticResource contextMenu}"/>
        <Setter Property="local:ComboBoxContextMenuBehavior.IsContextMenuBound"
            Value="True"/>
    </Style>
</Window.Resources>

<ComboBox IsEditable="True"/>

...and that's all you need. You have now successfully added a TemplateBinding to the ComboBox without subclassing it, and without individually referencing each ComboBox as a Style is used to fix the problem.

So, in conclusion, this bug is annoying but can be easily worked around whether it is acceptable or not to subclass the ComboBox.

Download sample app with source code

Setting up Theme-Specific Resource Dictionaries

2008-11-28T11:36:00.015Z

Configuring theme-specific resource dictionaries is a common stumbling block. Follow these rules to ensure they are set up correctly:

1. In the AssemblyInfo for your assembly, set the ThemeInfo attribute. This will specify where the theme-specific and generic resource dictionaries for the styleable resources referenced and defined in the assembly can be found.

[assembly: ThemeInfo(
    ResourceDictionaryLocation.SourceAssembly, 
    // Where theme-specific resource dictionaries are located.
    // (Used if a resource is not found in the page, 
    // or application resource dictionaries.)
 
    ResourceDictionaryLocation.SourceAssembly 
    // Where the generic resource dictionary is located.
    // (Used if a resource is not found in the page, 
    // app, or any theme specific resource dictionaries.)
)]

2. Put your theme-specific resource dictionaries in the Themes folder of the relevant assembly so they will be automatically picked up (do not use LoadComponent). Also add a generic resource dictionary with the name generic.xaml.

3. Any control-specific theme-specific resource dictionaries should also be added to the Themes folder. The dictionary should then be merged into a main resource dictionary like this:

<!-- Aero.NormalColor.xaml: -->
<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary
        Source="/MyAssemblyName;component/Themes/MyControl.Aero.NormalColor.xaml"/>
</ResourceDictionary.MergedDictionaries>

4. Do the same with any control-specific generic resource dictionaries:

<!-- generic.xaml: -->
<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary
        Source="/MyAssemblyName;component/Themes/UnthemedControl.generic.xaml"/>
</ResourceDictionary.MergedDictionaries>

5. Any resources defined in your assembly required to pick up styles from the theme-specific or generic resource dictionaries should override the default style key in their static constructor. You should also do this if you want to override the default style of the base class of the resource.

// Register the default style for MyControl.
DefaultStyleKeyProperty.OverrideMetadata(typeof(MyControl), 
    new FrameworkPropertyMetadata(typeof(MyControl)));

6. If you want to set the style of a control not defined in your assembly, you will need to explicitly load the resource dictionary:

ResourceDictionary dict = Application.LoadComponent(
    new Uri("MyAssemblyName;component/Themes/NewDefaultStyle.xaml", UriKind.Relative))
    as ResourceDictionary;

Application.Current.Resources.MergedDictionaries.Add(dict);

...and that's it! That should cover everything you need to do to get your resources picking up their styles from the correct place.

Download Full Source Code

Notification when items are added or removed from an ItemsControl(ListBox, TabControl, TreeView etc.)

2008-11-27T11:55:00.006Z

It's not obvious how to listen to changes to the Items of an ItemsControl. This post outlines various problems and identifies a simple way to listen to this collection regardless of how the ItemsControl was populated.

In general, there are two ways to add items to an ItemsControl:

Manually add to the ItemCollection of the control. This is accessed using the Items property of the control.
Assign a notifying source to the ItemsSource of the control. This will update the Items of the control automatically as the collection changes.

If you are adding items manually to your ItemsControl, then listening to changes isn't such a big deal since you can just call a method after you have added an item. If you are using an ItemsSource, however, then listening to changes is often required for UI tasks such as bringing a new item into view.

The standard way of listening to a notifying source is by using a CollectionViewSource. If you were to attempt to use it to listen to the items of a ListBox you would do something like this:

<Window.Resources>
    <CollectionViewSource x:Key="cvs" x:Name="cvs" Source="{Binding}"/>
</Window.Resources>
       
<ListBox x:Name="mListBox" ItemsSource="{Binding}"/>

public MyWindow()
{
    InitializeComponent();
    
    CollectionViewSource cvs = (CollectionViewSource)FindResource("cvs");
 cvs.View.CollectionChanged += View_CollectionChanged;
}

private void View_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
    if (e.Action == NotifyCollectionChangedAction.Add)
    {
        // scroll the new item into view
        mListBox.ScrollIntoView(e.NewItems[0]);
    }   
}

To me, this is quite an ugly solution since it isn't resistant to a change of ItemsSource on the ListBox. At first, it seems this could be fixed by binding the Source of the CollectionViewSource directly to the ListBox:

<Window.Resources>
    <CollectionViewSource x:Key="cvs" x:Name="cvs" 
        Source="{Binding ElementName=mListBox, Path=ItemsSource}"/>
</Window.Resources>
       
<ListBox x:Name="mListBox" ItemsSource="{Binding}"/>

But this doesn't help. Since the View property of the CollectionViewSource has no update mechanism (it isn't a dependency property), there's no way of knowing when it changes.

A different approach is required...

The first thing most developers look for when attacking this problem is an event handler on Items. But, when you look at the members generated by Intellisense you find...

...that there's no CollectionChanged event handler here, so how do you listen to changes in the collection?

The problem is that the INotifyCollectionChanged interface which contains the event handler is explicitly implemented, which means you have to first cast the ItemCollection before the event handler can be used:

public MyWindow()
{
    InitializeComponent();
    
    ((INotifyCollectionChanged)mListBox.Items).CollectionChanged +=
        mListBox_CollectionChanged;
}

private void mListBox_CollectionChanged(object sender, 
    NotifyCollectionChangedEventArgs e)
{
    if (e.Action == NotifyCollectionChangedAction.Add)
    {
        // scroll the new item into view
        mListBox.ScrollIntoView(e.NewItems[0]);
    }    
}

Ta da! This is much better - it's simple and robust.

So, in conclusion, this is the best way to listen to changes to the Items of an ItemsControl. There's no messing about with CollectionViewSource and worrying about updating when a new ItemsSource is assigned...it works regardless of whether ItemsSource is being used and is resistant to changes in ItemsSource.

Understand Bubbling and Tunnelling in 5 minutes

2008-11-26T12:11:00.011Z

Here's a quick and visual way to understand Routed Events and their bubbling and tunnelling nature.

1. Download and run Snoop. It is a fantastic utility for debugging WPF applications.
2. Run a WPF application, and Snoop it using Snoop's binoculars button. I'm using Expression Blend in this example.
3. Snoop can display the visual tree of your application at run time. Move your cursor over a visual element in your application and hold down the Shift and Control keys. The element will now have a red border and Snoop will pop up the Visual Tree for your application with the element selected like this:

4. Click on the Events tab at the top of the right hand pane. This tab contains a list which records all routed events that hit the selected element.
5. Open the combo box at the top of the right hand pane. Here you can check the Routed Events that you are interested here.

6. In the list, uncheck everything except MouseDown and PreviewMouseDown. These are the routed events that we will look at.
7. Clear the list of recorded routed events by clicking the X button to the right of the combo box at the top of the right hand pane.
8. Go back to the selected element in your app and click on it. Notice that this will have been recorded in Snoop. If an entry is shown in green, then it has been handled.

9. Now expand the PreviewMouseDown entry in the right hand pane and look at the list the elements which are shown. It will be something like this:

10. Here's the interesting bit. Click down the list one-by-one starting at the top. As you do this, notice that the selection in the Visual Tree in the left hand pane starts at the top and moves downwards. This is because PreviewMouseDown is a Tunnelling routed event, that is, it is first received by the top-most parent element and then goes down the visual tree one by one until it reaches the bottom element. If any of the elements handle the event and set e.Handled = true then the event stops being routed there.
11. Now expand the MouseDown entry and look at the list of elements shown.

12. Since MouseDown is a Bubbling routed event, it is first received by the bottom element and then bubbles up the visual tree one by one until it reaches the top element. If any of the elements handle the event and set e.Handled = true then the event stops being routed there.

So there you have it, Snoop is a great tool for debugging WPF applications and an easy way to observe and unserstand what is going with your routed events.

For more detailed information about the motivation for the design of routed events, visit the MSDN page for routed events here.

How to set bindings on CLR Properties using DataResource

2008-11-21T10:35:00.077Z

It can be pretty annoying that bindings are only allowed on dependency properties of elements that are part of an element tree. For example, in all of these scenarios binding isn't allowed:

on an InputBinding's CommandParameter (not a dependency property)
on an object in an element's Resources if that object doesn't derive from Freezable (not part of an element tree)
on an element set to a FrameworkElement’s Tag property (not part of an element tree)
on a ValidationRule (not a dependency object)

This post introduces a new technique allowing you to add bindings to CLR properties and is a perfectly good workaround for all the scenarios above. it's good because it:

helps you use binding in many more scenarios :)

is very easy to use: just drop one source file (DataResource.cs) into your app and use it like this:


<Window.Resources>
    
    <my:DataResource x:Key="actualWidth" BindingTarget="{Binding ActualWidth}"/>
</Window.Resources>

<my:MyControl>
    <my:MyControl.MyClrProperty>
        <my:DataResourceBinding DataResource="{StaticResource actualWidth}"/>
    </my:MyControl.MyClrProperty>
</my:MyControl>

It works by using:

Mike Hillberg's technique of using Freezable to gain access to the DataContext of the host element
a custom markup extension to retrieve the object that the DataResource is bound to and returns this as the host of the markup extension

DataResource.cs
Download sample app with source code