Bea Stollnitz

New look

Bea — Tue, 23 Jun 2009 22:24:46 +0000

My blog has a fresh new look! If you use a blog reader, make sure you go to the site to check it out! I’d love to hear your feedback about it, especially if it doesn’t work correctly in your favorite browser (unless your favorite browser is IE6…).

Also, some of you may have noticed that I changed domain name a while ago, from www.beacosta.com to bea.stollnitz.com, to reflect my name change. I will keep the old domain name working for a while, but eventually I plan to let it go, so make sure you update any links to my blog with the new domain.

I also included my email address in this site (on the top right corner).

How can I expand items in a TreeView? – Part III

Bea — Wed, 31 Dec 2008 03:13:03 +0000

This is the third of a three-part series about expanding TreeViewItems. In the first post I explained how to use an implicit Style to expand all TreeViewItems at load time. In the second post I showed how you can drive expansion and selection of items using an intermediate data source. In this post, I will explain how you can expand and select TreeViewItems using the dispatcher.

Expanding all TreeViewItems by setting the IsExpanded property on the items directly is not as simple as doing a tree walk and marking this property as you go. The problem is that after expanding a TreeViewItem, you need to return control to WPF or Silverlight so that the children TreeViewItems can be instantiated, before it’s their turn to be expanded. Fortunately, the Dispatcher can be used on both of these technologies to ensure the instantiation of the TreeViewItems.

WPF

Those of you who have experience with previous Microsoft technologies may have used the “DoEvents” method in the past, which performs a non-blocking wait. WPF doesn’t ship an equivalent method, but it’s easy to implement similar behavior using the Dispatcher. I like using a version of this method that takes a DispatcherPriority, so that I have more control over when to resume execution of my code. You can take a look at the code I use below:

    internal static void WaitForPriority(DispatcherPriority priority)
    {
        DispatcherFrame frame = new DispatcherFrame();
        DispatcherOperation dispatcherOperation = Dispatcher.CurrentDispatcher.BeginInvoke(priority, new DispatcherOperationCallback(ExitFrameOperation), frame);
        Dispatcher.PushFrame(frame);
        if (dispatcherOperation.Status != DispatcherOperationStatus.Completed)
        {
            dispatcherOperation.Abort();
        }
    }

    private static object ExitFrameOperation(object obj)
    {
        ((DispatcherFrame)obj).Continue = false;
        return null;
    }

In the code above, you can see that I create a new DispatcherFrame and only exit from that frame once dispatcher operations of the specified priority are reached. This way, I will give WPF a chance to execute anything with a priority higher than the one passed as a parameter before continuing executing the next line of code. For example, in the following code I ensure that all jobs with priority higher than Background have been executed by the time I call MyMethod2.

    MyMethod1();
    WaitForPriority(DispatcherPriority.Background);
    MyMethod2();

If there is other work for the dispatcher to do at the priority specified, it is not guaranteed that that work will happen before starting execution of MyMethod2. Since the “ExitFrameOperation” method is BeginInvoked at Background priority in this case, it is possible that other tasks at the same priority will be executed after this one. For this reason, if you want to make sure all operations at Background priority have been executed, you should pass priority ContextIdle instead (the next priority level).

Now that you understand this very useful WaitForPriority method, we can look at how we can use it to expand all items in a TreeView. Expanding the first level of TreeViewItems is easy, but in order to expand the second level of items, we need to make sure that the TreeViewitems are fully instantiated. This can only be achieved by returning control back to WPF just long enough for those items to be instantiated, and then continue execution. This is the perfect job for WaitForPriority.

In the code below, I do a full non-recursive depth-first tree traversal, and for each item I encounter, I set IsExpanded to true and wait in a non-blocking way for the child TreeViewItems to be instantiated.

    private void ExpandAll(object sender, RoutedEventArgs e)
    {
        ApplyActionToAllTreeViewItems(itemsControl =>
        {
            itemsControl.IsExpanded = true;
            DispatcherHelper.WaitForPriority(DispatcherPriority.ContextIdle);
        },
        treeView);
    }

    private void ApplyActionToAllTreeViewItems(Action itemAction, ItemsControl itemsControl)
    {
        Stack itemsControlStack = new Stack();
        itemsControlStack.Push(itemsControl);

        while (itemsControlStack.Count != 0)
        {
            ItemsControl currentItem = itemsControlStack.Pop() as ItemsControl;
            TreeViewItem currentTreeViewItem = currentItem as TreeViewItem;
            if (currentTreeViewItem != null)
            {
                itemAction(currentTreeViewItem);
            }
            if (currentItem != null) // this handles the scenario where some TreeViewItems are already collapsed
            {
                foreach (object dataItem in currentItem.Items)
                {
                    ItemsControl childElement = (ItemsControl)currentItem.ItemContainerGenerator.ContainerFromItem(dataItem);
                    itemsControlStack.Push(childElement);
                }
            }
        }
    }

My explanation about collapsing TreeViewItems in the previous post is applicable to this scenario too. There are basically two ways you can collapse the item: you can either collapse just the top level items (in which case expanding them again will keep the previous expansion state) or you can collapse every single item in the tree (in which case the previous expansion state is lost).

    private void CollapseTopLevel(object sender, RoutedEventArgs e)
    {
        foreach (Taxonomy item in treeView.Items)
        {
            TreeViewItem tvi = treeView.ItemContainerGenerator.ContainerFromItem(item) as TreeViewItem;
            tvi.IsExpanded = false;
        }
    }

    private void CollapseAll(object sender, RoutedEventArgs e)
    {
        ApplyActionToAllTreeViewItems(itemsControl => itemsControl.IsExpanded = false, treeView);
    }

Expanding and selecting one tree node is a bit more complex using the dispatcher than it was using the intermediate data source. In the previous post, I was able to use recursion to look for the item, and as I returned from each level of the recursion, I expanded the item. So I started by expanding the bottom level node, and worked my way to the top. When using the intermediate data source solution this order didn’t matter because all items were updated in the same layout pass.

However, when interacting with the TreeViewItems directly, I always need to start expanding the nodes from the top and wait for the next level of nodes to be instantiated before proceeding. So the simple algorithm from the previous post won’t help me here. The solution is to do this in two parts: first I navigate the whole tree using recursion, find the item to expand, and as I return from each level of recursion, I create a collection with the parent hierarchy. Once I have that information, I can now start from the top of the tree and expand each TreeViewItem that corresponds to a data item in the collection.

    private void SelectOne(object sender, RoutedEventArgs e)
    {
        ArrayList treeOfLifeCollection = (ArrayList)this.Resources["treeOfLife"];
        Taxonomy elementToExpand = ((Taxonomy)treeOfLifeCollection[2]).Subclasses[3].Subclasses[0].Subclasses[0].Subclasses[0];

        foreach (Taxonomy firstLevelDataItem in treeView.Items)
        {
            Collection superclasses = GetSuperclasses(firstLevelDataItem, elementToExpand);
            if (superclasses != null)
            {
                // Expand superclasses
                TreeViewItem parentTreeViewItem = (TreeViewItem)treeView.ItemContainerGenerator.ContainerFromItem(firstLevelDataItem);
                parentTreeViewItem.IsExpanded = true;
                DispatcherHelper.WaitForPriority(DispatcherPriority.Background);

                foreach (Taxonomy superclassToExpand in superclasses.Skip(1))
                {
                    TreeViewItem treeViewItemToExpand = (TreeViewItem)parentTreeViewItem.ItemContainerGenerator.ContainerFromItem(superclassToExpand);
                    treeViewItemToExpand.IsExpanded = true;
                    DispatcherHelper.WaitForPriority(DispatcherPriority.Background);
                    parentTreeViewItem = treeViewItemToExpand;
                }

                // Select node
                TreeViewItem treeViewItemToSelect = (TreeViewItem)parentTreeViewItem.ItemContainerGenerator.ContainerFromItem(elementToExpand);
                treeViewItemToSelect.IsSelected = true;
            }
        }
    }

    private Collection GetSuperclasses(Taxonomy currentItem, Taxonomy itemToLookFor)
    {
        if (itemToLookFor == currentItem)
        {
            Collection results = new Collection();
            return results;
        }
        else
        {
            foreach (Taxonomy subclass in currentItem.Subclasses)
            {
                Collection results = GetSuperclasses(subclass, itemToLookFor);
                if (results != null)
                {
                    results.Insert(0, currentItem);
                    return results;
                }
            }
            return null;
        }
    }

If you were able to change your data source, a simpler alternative to this algorithm would be to add parent pointers to each data item. If you had parent pointers, instead of using recursion in the GetSuperclasses method, you could find the parent hierarchy with a simple for loop. If you were not able to change the data source but your data source used an ObservableCollection to store the children of each data item, yet another option would be to add an intermediate data source that listens to collection changes in the original data, and adds parent pointers to the intermediate data when items are added. However, I didn’t want to provide a solution that assumes you can change your data source, because often you can’t. And I didn’t want to assume your source uses ObservableCollection because often it doesn’t. I am certain that if you have the luxury of parent pointers or collection change notifications, you will be able to write the corresponding code easily.

I’d provide a link to the running xbap here, but that’s not possible for this example because DispatcherFrame can’t be used in the partial-trust security model of an xbap. Instead, you’ll have to build the WPF example from the source code provided at the end of this post.

Silverlight

The Silverlight version of the Dispatcher solution is quite a bit different from the WPF one. Silverlight does not have DispatcherFrame or DispatcherPriority, so there is no way to write a helper method similar to DoEvents. Fortunately, the Silverlight Dispatcher has a BeginInvoke method that I can use to return control to Silverlight, and allow it to instantiate the next level of TreeViewItems before continuing. Take a look at the code below. By calling MyMethod2 asynchronously, I am ensuring that control is returned to Silverlight before MyMethod2 is executed. This is the technique I will use to allow Silverlight to instantiate the next level of TreeViewItems before I can expand them.

MyMethod1();
myElement.Dispatcher.BeginInvoke(MyMethod2);

You can see this technique being using to expand all TreeViewItems:

    private void ExpandAll(object sender, RoutedEventArgs e)
    {
        for (int i = 0; i < treeView.Items.Count; i++)
        {
            ExpandAllTreeViewItems((TreeViewItem)treeView.ItemContainerGenerator.ContainerFromIndex(i));
        }
    }

    private void ExpandAllTreeViewItems(TreeViewItem currentTreeViewItem)
    {
        if (!currentTreeViewItem.IsExpanded)
        {
            currentTreeViewItem.IsExpanded = true;
            currentTreeViewItem.Dispatcher.BeginInvoke(() => ExpandAllTreeViewItems(currentTreeViewItem));
        }
        else
        {
            for (int i = 0; i < currentTreeViewItem.Items.Count; i++)
            {
                TreeViewItem child = (TreeViewItem)currentTreeViewItem.ItemContainerGenerator.ContainerFromIndex(i);
                ExpandAllTreeViewItems(child);
            }
        }
    }

Similarly to the previous solutions, I show both how you can collapse all items or just the top level. Since we don’t have to wait for TreeViewItems to be instantiated when collapsing all items, it is not necessary to use BeginInvoke. Any tree walking algorithm would work.

    private void CollapseAll(object sender, RoutedEventArgs e)
    {
        for (int i = 0; i < treeView.Items.Count; i++)
        {
            CollapseAllTreeViewItems((TreeViewItem)treeView.ItemContainerGenerator.ContainerFromIndex(i));
        }
    }

    private void CollapseAllTreeViewItems(TreeViewItem rootTreeViewItem)
    {
        Stack treeViewItemsStack = new Stack();
        treeViewItemsStack.Push(rootTreeViewItem);
        while (treeViewItemsStack.Count != 0)
        {
            TreeViewItem current = treeViewItemsStack.Pop();
            current.IsExpanded = false;

            for (int i = 0; i < current.Items.Count; i++)
            {
                treeViewItemsStack.Push(current.ItemContainerGenerator.ContainerFromIndex(i) as TreeViewItem);
            }
        }
    }

    private void CollapseTopLevel(object sender, RoutedEventArgs e)
    {
        // This iterates through the three top-level items only.
        foreach (Taxonomy item in treeView.Items)
        {
            TreeViewItem tvi = treeView.ItemContainerGenerator.ContainerFromItem(item) as TreeViewItem;
            tvi.IsExpanded = false;
        }
    }

The code for expanding and selecting one item is also quite a bit different, and a bit more complex. In WPF, once we had all superclasses, we could navigate down the TreeView hierarchy with a for loop, as long as we remembered to return control to WPF after expanding each TreeViewItem. In Silverlight, I had to introduce a new ExpandPathAndSelectLast method that calls itself using BeginInvoke, giving an opportunity for Silverlight to create the next level of TreeViewItems between method calls. I don’t show the GetSuperclasses method again here, since it’s the same as the WPF version.

    private void SelectOne(object sender, RoutedEventArgs e)
    {
        ObjectCollection treeOfLifeCollection = (ObjectCollection)this.Resources["treeOfLife"];
        Taxonomy elementToExpand = ((Taxonomy)treeOfLifeCollection[2]).Subclasses[3].Subclasses[0].Subclasses[0].Subclasses[0];

        foreach (Taxonomy firstLevelDataItem in treeView.Items)
        {
            Collection superclasses = GetSuperclasses(firstLevelDataItem, elementToExpand);
            if (superclasses != null)
            {
                TreeViewItem parentTreeViewItem = (TreeViewItem)treeView.ItemContainerGenerator.ContainerFromItem(firstLevelDataItem);
                ExpandPathAndSelectLast(parentTreeViewItem, superclasses.Skip(1).GetEnumerator(), elementToExpand);
            }
        }
    }

    private void ExpandPathAndSelectLast(TreeViewItem currentTreeViewItem, IEnumerator enumerator, object itemToSelect)
    {
        if (!currentTreeViewItem.IsExpanded)
        {
            currentTreeViewItem.IsExpanded = true;
            currentTreeViewItem.Dispatcher.BeginInvoke(() => ExpandPathAndSelectLast(currentTreeViewItem, enumerator, itemToSelect));
        }
        else if (enumerator.MoveNext())
        {
            object dataItem = enumerator.Current;
            TreeViewItem nextContainer = (TreeViewItem)currentTreeViewItem.ItemContainerGenerator.ContainerFromItem(dataItem);
            ExpandPathAndSelectLast(nextContainer, enumerator, itemToSelect);
        }
        else
        {
            TreeViewItem treeViewItemToSelect = (TreeViewItem)currentTreeViewItem.ItemContainerGenerator.ContainerFromItem(itemToSelect);
            treeViewItemToSelect.IsSelected = true;
        }
    }

This is all the code you need to expand and collapse TreeViewItems.

If you have Silverlight 2 installed, you can see a running version of this example in its own page or embedded below:

Which TreeView expansion solution should I use?

Now that you know of three ways to expand, collapse and select items in a TreeView, you’re faced with the decision of which one you should use in your project. Below I show a quick bullet-point list of the pros and cons of each solution. Hopefully this will help you make the right decision.

Solution 1 – Expand all TreeViewItems using an implicit style

Pros:

Really really simple to implement.

Cons:

It is only useful to expand all TreeViewItems at app startup.

Solution 2 – Expand, collapse and select TreeViewItems using an intermediate data source

Pros:

This is the fastest way to expand items, since they all get expanded in one layout pass. If you are binding your TreeView to a large amount of data, this may be your best option.

Cons:

If your data source is complex, it may be very hard to write an intermediate data source.

Solution 3 – Expand, collapse and select TreeViewItems using the Dispatcher

Pros:

It’s independent of the data source, so you can reuse the code in TreeViews bound to different data sources (in fact, you can even add these as extension methods on TreeView).
If you don’t have a lot of data, the visual effect of expanding one hierarchy level per layout pass can be fun.

Cons:

If your data has a deep hierarchy, it will be very slow to expand the items. It will take as many layout passes as levels in the hierarchy.

Download the WPF project (built with .NET 3.5 SP1).

Download the Silverlight project (built with Silverlight 2).

How can I expand items in a TreeView? – Part II

Bea — Fri, 14 Nov 2008 01:00:11 +0000

For those of you in Europe, I will be giving a talk at the Oredev conference in Malmo, Sweden, on Thursday the 20th of November. I hope I’ll get to meet some of you there.

In my last post, I showed how you can expand all items in a TreeView at load time. In WPF, this can be done by simply adding an implicit style to the resources, and in Silverlight we need a little help from ImplicitStyleManager to achieve the same behavior.

However, applications typically allow more complex interaction with a TreeView. In particular, they often permit users to expand all nodes, collapse all nodes, and expand the tree to reveal a particular node. I will show you one way to accomplish these tasks in this post, and a different way in my next post.

For the first approach, I will show you how to add an intermediate data layer to your application that adds UI-specific functionality on top of the data source. The idea of having an intermediate data layer isn’t new, and is explained in great detail by John Gossman in the context of WPF and Nikhil Kothari in the context of Silverlight.

WPF

I used the same “Taxonomy” data source in this post that you may already be familiar with from my previous post or from the Silverlight Toolkit’s sample pages.

For this sample, I decided that I wanted to allow users to perform three operations on the TreeView: expand all items, collapse all items, and expand just enough items to select a particular data item. To make these operations possible, I need a data source that has IsExpanded and IsSelected properties in each data item, so that I can data bind the corresponding properties of each TreeViewItem. Since my original data source does not contain these properties, I introduced an intermediate data source (sometimes called a view model) that has the properties I need.

There are a couple of ways to create an intermediate data source: you can either wrap the original data (containment) or you can derive from it (inheritance). Deriving may not be an option, if the data source is sealed or already has subclasses, so I chose the more general solution of containment for this sample. Here’s what my intermediate data source looks like at this point:

    public abstract class TaxonomyViewModel : INotifyPropertyChanged
    {
        public Taxonomy Taxonomy { get; private set; }

        private bool isExpanded;
        public bool IsExpanded
        {
            get { return isExpanded; }
            set
            {
                isExpanded = value;
                OnPropertyChanged("IsExpanded");
            }
        }

        private bool isSelected;
        public bool IsSelected
        {
            get { return isSelected; }
            set
            {
                isSelected = value;
                OnPropertyChanged("IsSelected");
            }
        }
        …
    }

Although wrapping is more flexible, it requires forwarding of properties and methods to the actual data items. I exposed the Classification and Rank properties of Taxonomy in the TaxonomyViewModel class, but the Subclasses collection presented a problem: a TaxonomyViewModel has as its “Subclasses” other TaxonomyViewModels, but a Taxonomy has “Subclasses” of type Taxonomy. For this reason, I had to create a parallel collection of the right type, and I had to make sure that changes to the collection in TaxonomyViewModel are propagated to Taxonomy.

    private TaxonomyViewModelCollection subclasses;
    public Collection Subclasses { get { return subclasses; } }

    private class TaxonomyViewModelCollection : Collection
    {
        private Collection originalCollection;

        public TaxonomyViewModelCollection(Collection originalCollection)
        {
            this.originalCollection = originalCollection;
        }

        protected override void InsertItem(int index, TaxonomyViewModel item)
        {
            base.InsertItem(index, item);
            originalCollection.Insert(index, item.Taxonomy);
        }
        …
    }

My next step was to add a method that expands all nodes. This method needs to traverse the whole hierarchy of data and set IsExpanded to true on all nodes. Any tree traversal algorithm would work – I chose to use a Stack to do a non-recursive depth-first traversal.

    public void ExpandAll()
    {
        ApplyActionToAllItems(item => item.IsExpanded = true);
    }

    private void ApplyActionToAllItems(Action itemAction)
    {
        Stack dataItemStack = new Stack();
        dataItemStack.Push(this);

        while (dataItemStack.Count != 0)
        {
            TaxonomyViewModel currentItem = dataItemStack.Pop();
            itemAction(currentItem);
            foreach (TaxonomyViewModel childItem in currentItem.Subclasses)
            {
                dataItemStack.Push(childItem);
            }
        }
    }

Now that the code for traversing the tree is already in place, collapsing all TreeViewItems can be done in one line. The result of setting IsExpanded to false in all nodes will have effect in the same layout pass (since I don’t return control to Silverlight during the tree traversal), so the order in which the IsExpanded properties are set does not matter. All items in the TreeView will collapse at the same time, in one layout pass.

    public void CollapseAll()
    {
        ApplyActionToAllItems(item => item.IsExpanded = false);
    }

And finally, I added a method that, given a data item, expands all the items in its ancestor chain. This method uses recursion to search for the data item passed as a parameter. Once the item is found, its ancestor chain gets expanded as the recursive call stack unwinds.

    public bool ExpandSuperclasses(TaxonomyViewModel itemToLookFor)
    {
        return ApplyActionToSuperclasses(itemToLookFor, superclass => superclass.IsExpanded = true);
    }

    private bool ApplyActionToSuperclasses(TaxonomyViewModel itemToLookFor, Action itemAction)
    {
        if (itemToLookFor == this)
        {
            return true;
        }
        else
        {
            foreach (TaxonomyViewModel subclass in this.Subclasses)
            {
                bool foundItem = subclass.ApplyActionToSuperclasses(itemToLookFor, itemAction);
                if (foundItem)
                {
                    itemAction(this);
                    return true;
                }
            }
            return false;
        }
    }

And that’s all for the intermediate data source. Now we need to hook this up to the UI. I started by adding three buttons that call the methods I just wrote. Because a TreeView can actually contain multiple trees, my button event handlers iterate over all the root items, calling the appropriate method.

            …


            …


            …



    private void ExpandAll(object sender, RoutedEventArgs e)
    {
        foreach (TaxonomyViewModel item in treeView.Items)
        {
            item.ExpandAll();
        }
    }

    private void SelectOne(object sender, RoutedEventArgs e)
    {
        ArrayList treeOfLifeCollection = (ArrayList)this.Resources["treeOfLife"];
        TaxonomyViewModel elementToExpand = (TaxonomyViewModel)((TaxonomyViewModel)treeOfLifeCollection[2]).Subclasses[3].Subclasses[0].Subclasses[0].Subclasses[0];

        foreach (TaxonomyViewModel item in treeView.Items)
        {
            if (item.ExpandSuperclasses(elementToExpand))
            {
                elementToExpand.IsSelected = true;
                break;
            }
        }
    }

The CollapseAll scenario is a bit of a special case. There are really two options for collapsing all items:

You can set IsExpanded to false on every TreeViewItem. The CollapseAll method I showed earlier can be used in this case. If you pick this option, any previous item expansion is forgotten once you collapse all items. This means that if you expand a few items, collapse all, and expand one top level item, the previous item expansion will not be restored.

    private void CollapseAll(object sender, RoutedEventArgs e)
    {
        foreach (TaxonomyViewModel item in treeView.Items)
        {
            item.CollapseAll();
        }
    }

The other option is to collapse only the top level items. If you pick this option, previous expansions will be remembered and restored after collapsing all items.

    private void CollapseTopLevel(object sender, RoutedEventArgs e)
    {
        foreach (TaxonomyViewModel item in treeView.Items)
        {
            TreeViewItem tvi = treeView.ItemContainerGenerator.ContainerFromItem(item) as TreeViewItem;
            tvi.IsExpanded = false;
        }
    }

And last, I need to bind the TreeViewItem’s IsExpanded and IsSelected properties to the corresponding properties in my intermediate data source. At first sight, it may seem that the following XAML would work well:

If you try this, however, you will notice that once you collapse a TreeViewItem manually by clicking on it, the Expand All button will no longer affect that item. That’s because when interacting directly with the UI, the IsExpanded property is set explicit, overwriting the binding. The solution is to make the Bindings two-way. As you would expect, two-way Bindings are not lost when the target value is set, they simply propagate the value back to the source.

If you have WPF installed on your machine, you can click here to see this code running as an xbap. I also link to the source at the end of this post.

Silverlight

Most of the code and XAML I showed for WPF works in Silverlight too, with the exception of the Binding in the Setter’s Value, since Silverlight currently doesn’t support that feature. In order to work around this limitation, I created custom TreeView and TreeViewItem classes that derive from the Toolkit classes and override GetContainerForItemOverride. This method is called to create each TreeViewItem container, so I was able to include the Bindings through code at the moment these containers are created.

    public class MyTreeView : TreeView
    {
        protected override DependencyObject GetContainerForItemOverride()
        {
            MyTreeViewItem tvi = new MyTreeViewItem();
            Binding expandedBinding = new Binding("IsExpanded");
            expandedBinding.Mode = BindingMode.TwoWay;
            tvi.SetBinding(MyTreeViewItem.IsExpandedProperty, expandedBinding);
            Binding selectedBinding = new Binding("IsSelected");
            selectedBinding.Mode = BindingMode.TwoWay;
            tvi.SetBinding(MyTreeViewItem.IsSelectedProperty, selectedBinding);
            return tvi;
        }
    }

Also, unfortunately we have a bug in the Toolkit TreeView that occasionally causes more than one item to appear selected. Hopefully we’ll get that fixed for the next release.

If you have Silverlight 2 installed, you can see a running version of this example in its own page, or embedded below:

And that’s all for today. In my next post, I will discuss a third way of expanding, collapsing and selecting TreeViewItems.

Download the WPF project (built with .NET 3.5 SP1).

Download the Silverlight project (built with Silverlight 2).

How can I expand items in a TreeView? – Part I

Bea — Wed, 29 Oct 2008 22:32:02 +0000

Exciting!

Yesterday, the new Silverlight Toolkit (the team I now work for) was made available in CodePlex. This was announced by Scott Guthrie in his PDC keynote and by my manager Shawn Burke in his blog.

We created the Silverlight Toolkit to provide developers with a set of reusable components that maximize productivity and help take Silverlight to the next level. The toolkit is available under the Microsoft Public License, so we provide the full source code (as well as tests and samples), and encourage you to reuse our code in your applications.

If you want to know more about it, I recommend that you check out our web site, download the toolkit, and post questions in the Silverlight controls forum. My team just went through a resource-constrained, short, crazy release, where everyone on the team went beyond at so many levels, so it feels amazing to get these bits out to customers.

Expanding items in a TreeView

Among many other controls, we shipped a Silverlight TreeView, nearly identical to the WPF one. This is the first of three blog posts in which I am going to discuss different ways of expanding the items in a TreeView. These blog posts will cover both WPF and Silverlight, and point out the differences between the two. I’m hoping this will be especially useful to those of you who are familiar with one technology and interested in learning the other.

I have encountered customers in the past who had implemented complex solutions to expand all items of a TreeView at load time (which is a pretty common scenario). This scenario is actually really easy to accomplish – you can simply add an implicit Style for TreeViewItem that sets IsExpanded to true.

WPF

In WPF, this can be done by adding an implicit style to the resources of your page:

            …

        …

Couldn’t be any easier.

If you have WPF installed on your machine, you can click here to see this code running as an xbap. I also link to the source at the end of this post.

Silverlight

Now let’s look at the differences between the WPF solution and the corresponding Silverlight one.

You may have noticed that I used an ArrayList to store my data source in the WPF sample. Usually I would prefer to use a strongly typed generic collection, but for this example I chose ArrayList because the WPF XAML parser does not yet support generic types. In Silverlight, the ArrayList type is not available for customer use (it’s internal), so I used an ObjectCollection instead. ObjectCollection is a new collection type we ship in the Silverlight toolkit exactly for the purpose of defining collections in XAML. Here is its source code:

    public partial class ObjectCollection : Collection
    {
        public ObjectCollection()
        {
        }

        public ObjectCollection(IEnumerable collection)
        {
            foreach (object obj in collection)
            {
                Add(obj);
            }
        }
    }

In this case I don’t need collection change notifications, so deriving from Collection works well for me, without adding the overhead of ObservableCollection. If you need collection change notifications, you can use the same technique and simply replace the base class with ObservableCollection.

The Style for the TreeViewItem looks really similar to the WPF one. However, if you try this in Silverlight, you will notice that the style doesn’t get applied.

        …

This is because Silverlight doesn’t have support for implicit styles. When using the Silverlight runtime, you need to give each style a key and refer to it explicitly using StaticResource. Because the TreeViewItems are generated automatically by the TreeView, it would be pretty hard to specify an explicit style for each one.

Fortunately, the Silverlight Toolkit contains a solution to this problem that provides a behavior similar to WPF’s implicit styles. You can use the “ImplicitStyleManager” class, and in particular its ApplyMode attached property:

And now the implicit style is applied and the TreeView expands all items on load! If you have Silverlight 2 installed, you can see a running version of this example in its own page, or embedded below:

ImplicitStyleManager

ImplicitStyleManager only affects elements in the subtree rooted at the element where ApplyMode is set. In the sample above, implicit styles are only applied to the TreeView itself and its descendants in the visual tree (TreeViewItems, etc.). However, when searching for styles to use, ImplicitStyleManager looks within resource dictionaries in the entire name scope of the element where ApplyMode is set, as well as in the Application’s resources (just like in WPF). In this sample, it looks for implicit styles anywhere within the current UserControl (each UserControl defines a name scope), and in the Application’s resources.

You’ve already seen how to use ImplicitStyleManager in a simple scenario above, but this class provides some additional functionality. ISM (as we lovingly call it) has three different modes, which can be specified through its ApplyMode property:

Auto

ISM reapplies implicit styles every time layout is updated. So, if elements are added later to the visual tree (like the TreeViewItems in this sample), they will be implicitly styled.

Keep in mind that the LayoutUpdated event fires quite frequently (not just when elements are added to the visual tree), and walking the whole visual tree may be an expensive operation if you have a large tree. Unfortunately there is no “ItemAddedToTree” event that we could listen to, so we had to compromise on performance to offer the convenience of this mode.

In this post’s sample, the visual tree is small and very dynamic, so it makes sense to use this mode. But if your tree is relatively static or very large, you should consider using the OneTime mode instead.

OneTime

In this mode, ISM applies the implicit styles to the elements in the visual tree at load time. If new elements get added later, they will not be styled. In this blog’s sample, the generated TreeViewItems are not all instantiated at load time, so using ApplyMode=OneTime wouldn’t work.

Sometimes you may have a scenario where new items are added to the tree occasionally, but your tree is large enough that you would rather not use the Auto mode. For these situations, you can set ApplyMode to OneTime, and call ISM’s “Apply” method through code every time you want to reapply the styles. This provides extra flexibility while avoiding the performance cost of the Auto mode.

None

This mode is exactly the same as not attaching the ApplyMode property. It does not prevent styles from being propagated to the subtree where this property is set, as some people may expect. Since WPF doesn’t permit you to disable implicit styling within a subtree, ImplicitStyleManager doesn’t either.

There is more to ImplicitStyleManager than what I’ve explained here, so stay tuned for future posts.

Download the WPF project (built with .NET 3.5 SP1).

Download the Silverlight project (built with Silverlight 2).

How can I drag and drop items between data bound ItemsControls?

Bea — Fri, 22 Feb 2008 11:40:42 +0000

In this blog post, I will explain how I implemented a sample that allows you to drag and drop items between data bound ItemsControls. Imagine you have two or more data bound (or not data bound) ItemsControls in the same Window. You may want to drag an item from an ItemsControl and drop it on another one. Or maybe you want to drag and drop it in a different position within the same ItemsControl. The code in this blog post allows you to do those operations.

Use this code

You don’t need to understand the implementation details of this sample to take advantage of its functionality. If you want to use this code in your app, you should copy three files from the project at the end of the post – DraggedAdorner.cs, InsertionAdorner.cs and DragDropHelper.cs. You may want to change the namespace in these files. Then, within your app, you simply need to add three attached properties:

IsDropTarget should be set on the ItemsControl that you want to drag items to. This property is of type boolean and should be set to true. Don’t forget to add a namespace mapping on the top window that maps to the namespace you chose for DragDropHelper.

xmlns:local="clr-namespace:DragDropListBox" … />

local:DragDropHelper.IsDropTarget="true" …/>

IsDragSource should be set on the ItemsControl that you want to drag items from. This property should also be set to true.

DragDropTemplate should also be set on the drag source ItemsControl (where you want to drag the items from). This property should be set to a DataTemplate that controls how the data item should be displayed while it is dragged around. If you want it to be displayed exactly the same way as in the source ItemsControl, the DragDropTemplate and ItemTemplate properties can share the same template.

local:DragDropHelper.IsDragSource="true" local:DragDropHelper.DragDropTemplate="{StaticResource pictureTemplate}"/>

And that’s all there is to it. Next I will show the list of features and limitations of this solution.

Features

The code in this sample enables the user to drag and drop between ItemsControls and any controls that derive from it (see exception for TreeView in the limitations section).
This solution supports dragging and dropping within the same ItemsControl.
This solution supports dragging and dropping between non data bound and data bound ItemsControls.
I’ve added support for ItemsControls that use FlowPanel and StackPanel (with both horizontal and vertical orientation). Support for other panels can be added easily.
This sample prevents the user from dropping a data item into a target ItemsControl when its data items are of an incompatible type. For example, if the drag source ItemsControl contains a collection of Potatoes but the drop target ItemsControl is data bound to a collection of Squirrels, the app will prevent the user from doing the drop.
This sample provides visual feedback of where the dragged item will go if dropped. For example, when dragging a data item over a ListBox, this sample shows a horizontal line between the two items where the item will go if dropped.

Limitations

This solution doesn’t drag and drop data items across Windows.
It also doesn’t work across Applications.
It allows drag and drop to work between ItemsControls, but it does not allow you to drag or drop to a ContentControl.
This sample works as expected for the first level of a TreeView, but not for nested levels of the hierarchy.

Overview

To implement a drag and drop operation, we need to attach handlers for several events on the drag source and drop target elements. In this scenario, I decided that I am going to support only ItemsControls as the source and target of the drag and drop operation. All the events that I need to provide handlers for are public, so I could have easily done that in the Window1.xaml.cs file. However, I wanted an easily reusable solution that would allow all the drag-and-drop-specific code to be abstracted in one place. I thought of three different solutions to this problem (although I’m sure there are more):

I could derive from ItemsControl and override “OnPreviewMouseLeftButtonDown” and all the other “On” methods that correspond to the events I care about. I don’t like this solution so much because users would have to replace their ItemsControls with my custom “DragAndDropItemsControl”.

I could create a DragHelper class that takes an instance of the drag source ItemsControl as a parameter, and a DropHelper class that takes the drop target. The only disadvantage of this solution is that it needs to be set up from code.

Instead, I decided to create a DragDropHelper class that defines properties to be attached to the drag source and drop target IsDragSource and IsDropTarget. The main advantages of this solution are that it can be implemented entirely in XAML, and that the XAML changes are minimal (you only need to set these properties). I’ll explain below how this works.

These two attached properties are of type boolean, and should be attached to the drag source and drop target. When they’re set to false, dragging/dropping is not allowed, otherwise it is. If your application requires drag and drop operations to be allowed sometimes but not other times, you can simply change the properties on the fly.

When registering the attached properties, I made sure I passed change handlers called IsDragSourceChanged and IsDropTargetChanged to the UIPropertyMetadata. These methods are responsible for adding and removing handlers for the desired events, depending on the value of the attached property. I will show here the code for IsDragSourceChanged (the code for the target is similar):

    private static void IsDragSourceChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e)
    {
        var dragSource = obj as ItemsControl;
        if (dragSource != null)
        {
            if (Object.Equals(e.NewValue, true))
            {
                dragSource.PreviewMouseLeftButtonDown += Instance.DragSource_PreviewMouseLeftButtonDown;
                dragSource.PreviewMouseLeftButtonUp += Instance.DragSource_PreviewMouseLeftButtonUp;
                dragSource.PreviewMouseMove += Instance.DragSource_PreviewMouseMove;
            }
            else
            {
                dragSource.PreviewMouseLeftButtonDown -= Instance.DragSource_PreviewMouseLeftButtonDown;
                dragSource.PreviewMouseLeftButtonUp -= Instance.DragSource_PreviewMouseLeftButtonUp;
                dragSource.PreviewMouseMove -= Instance.DragSource_PreviewMouseMove;
            }
        }
    }

I describe below the events that I provided handlers for. I had to use the preview versions of these events to make sure I handle them before other controls do (for example, ListBox handles MouseLeftButtonDown).

ItemsControl Drag Source

PreviewMouseLeftButtonDown Its main responsibility is to remember the data item that the user clicked on.

    this.sourceItemContainer = Utilities.GetItemContainer(this.sourceItemsControl, visual);
    if (this.sourceItemContainer != null)
    {
        this.draggedData = this.sourceItemContainer.DataContext;
    }

PreviewMouseMove For a drag to happen, the user needs to click on the drag source and move the mouse by a significant amount. When a user performs a button click, there is a pretty high likelihood that the mouse will move inadvertently by a small amount, and I want to ignore those situations. Fortunately, there is a SystemParameter that can be used in these situations, so I make sure that the mouse has moved by at least SystemParameters.MinimumHorizontalDragDistance or SystemParameters.MinimumVerticalDragDistance before I consider it a drag. Once I decide a drag has started, I initiate the drag-and-drop operation. Notice below that I am initiating the drag operation with the data that I determined in the PreviewMouseLeftButtonDown handler (draggedData).

    DataObject data = new DataObject(this.format.Name, this.draggedData);
    …
    DragDropEffects effects = DragDrop.DoDragDrop((DependencyObject)sender, data, DragDropEffects.Move);

PreviewMouseLeftButtonUp This happens when the user releases the mouse without initiating a drag-and-drop operation. In this case, I simply set the draggedData field to null.

this.draggedData = null;

ItemsControl Drop Target

PreviewDragEnter This event fires every time the user first drags a data item into an element with AllowsDrop=true (I set this property on the drop target ItemsControl within the IsDropTargetChanged method, so you don’t have to). Since this property is inherited, this handler will be called every time the mouse enters any element that belongs to the visual tree of the drop target ItemsControl. Among other things, within this handler I have code that updates the two adorners that I will explain later in this post.

PreviewDragOver This event fires when the user drags the data item over elements with AllowsDrop=true. Similarly to the previous handler, the adorners are updated in this handler.

PreviewDragLeave As expected, this event fires when the mouse leaves an element that has AllowsDrop=true. Here, I remove one of the adorners. More details on the adorners later.

PreviewDrop This event notifies us that the drop operation has actually occurred. Here, I remove the data item from the drag source ItemsControl’s collection and add it to the drop target.

    object movedItem = e.Data.GetData(this.format.Name);
    …
    indexRemoved = Utilities.RemoveItemFromItemsControl(this.sourceItemsControl, movedItem);
    …
    Utilities.InsertItemInItemsControl(this.targetItemsControl, movedItem, this.insertionIndex);

Dragging and dropping data

There are several problems that are particular to dragging and dropping data items between ItemsControls. I will discuss a few of those next.

When dragging a data item over the target ItemsControl, I need to determine where the item will go if dropped. I broke down this scenario into three possible different situations:

The mouse is over an empty ItemsControl. In this case, if the ItemsControl is data bound to an empty collection the item gets added as the first and only item of that collection; similarly, if the ItemsControl is empty and not data bound, the item is added to the Items collection of the ItemsControl.

The ItemsControl has items, although the mouse is over the empty part of the ItemsControl, after the last item. In this case, the item should be added to the end of the ItemsSource or Items collection.

Last, the mouse could be over an item container. In this case, I need to determine whether I should insert the dragged data before or after the item under the mouse. If the ItemsControl uses a panel with vertical orientation, I check to see whether the mouse is over the top half or bottom half of the item container. Similarly, if the panel is laid out horizontally, I check to see whether the mouse is over the left half or right half of the item container.

This leads me to the next topic: I had to store the orientation of the panel so that I could calculate the insertion location when dropping over an item container. This calculation is done in the following method:

    public static bool HasVerticalOrientation(FrameworkElement itemContainer)
    {
        bool hasVerticalOrientation = true;
        if (itemContainer != null)
        {
            Panel panel = VisualTreeHelper.GetParent(itemContainer) as Panel;
            StackPanel stackPanel;
            WrapPanel wrapPanel;

            if ((stackPanel = panel as StackPanel) != null)
            {
                hasVerticalOrientation = (stackPanel.Orientation == Orientation.Vertical);
            }
            else if ((wrapPanel = panel as WrapPanel) != null)
            {
                hasVerticalOrientation = (wrapPanel.Orientation == Orientation.Vertical);
            }
            // You can add support for more panel types here.
        }
        return hasVerticalOrientation;
    }

Notice that I am providing support only for StackPanel and WrapPanel here, but you can easily add more “if” statements to support other panels.

Once I have the panel’s orientation information, I can determine whether the dragged data should be inserted before or after the item container under the mouse. In the code below, “first half” means the left half for a horizontally oriented panel, and top half for a vertically oriented one.

    public static bool IsInFirstHalf(FrameworkElement container, Point clickedPoint, bool hasVerticalOrientation)
    {
        if (hasVerticalOrientation)
        {
            return clickedPoint.Y < container.ActualHeight / 2;
        }
        return clickedPoint.X < container.ActualWidth / 2;
    }

Finally, I wanted to give the user feedback when a certain data item type can not be added to the drop target collection. To achieve this, I wrote a method called IsDropDataTypeAllowed, from which the following code snippet was taken. The drop operation is allowed if the target collection is of type IList where the dragged type can be assigned to type T, or if the target collection is of type IList, or if the drop target is not data bound. If none of the above is true, the cursor will change to a slashed circle to indicate that a drop is not allowed in that location.

    Type draggedType = draggedItem.GetType();
    Type collectionType = collectionSource.GetType();

    Type genericIListType = collectionType.GetInterface("IList`1");
    if (genericIListType != null)
    {
        Type[] genericArguments = genericIListType.GetGenericArguments();
        isDropDataTypeAllowed = genericArguments[0].IsAssignableFrom(draggedType);
    }
    else if (typeof(IList).IsAssignableFrom(collectionType))
    {
        isDropDataTypeAllowed = true;
    }
    else
    {
        isDropDataTypeAllowed = false;
    }

Dragged Adorner

As I mentioned earlier, the DragDropHelper class contains a DragDropTemplate attached property that should be set to the DataTemplate responsible for determining the look of the dragged data item. The DraggedAdorner’s main responsibility is to provide a representation for the dragged data using that DataTemplate. To achieve this behavior, I decided that the adorner’s only child should be a ContentPresenter with its Content set to the dragged data, and its ContentTemplate set to the DataTemplate specified in the DragDropTemplate attached property. I also decided to give the adorner a bit of transparency, so I set the Opacity of the ContentPresenter to 0.7. Here is the constructor for this adorner:

    public DraggedAdorner(object dragDropData, DataTemplate dragDropTemplate, UIElement adornedElement, AdornerLayer adornerLayer)
        : base(adornedElement)
    {
        this.adornerLayer = adornerLayer;

        this.contentPresenter = new ContentPresenter();
        this.contentPresenter.Content = dragDropData;
        this.contentPresenter.ContentTemplate = dragDropTemplate;
        this.contentPresenter.Opacity = 0.7;

        this.adornerLayer.Add(this);
    }

And here is what this adorner looks like, with the template I specified in this blog’s project:

There’s a bit more logic in this adorner class, such as the code that allows the adorner to follow the position of the mouse and the code that sets up the ContentPresenter as the adorner’s child visual.

Next I will explain briefly when this adorner is created, removed, and updated.

The DraggedAdorner is created:

When the user first drags data into an element belonging to the drop target DropTarget_PreviewDragEnter. This event is fired every time we enter a new element in the target’s tree, but we only need to create the Dragged Adorner the first time.
Every time we re-enter the Window TopWindow_DragEnter.

The DraggedAdorner is removed:

When dropping the item in a valid area DropTarget_PreviewDrop.
When leaving the window TopWindow_DragLeave.
If I drop the item in an invalid area, the drop handler doesn’t get called but the Window’s leave handler does, so this scenario is covered.

The DraggedAdorner is updated:

Every time the cursor moves over the drop target or anywhere else within the window. DropTarget_PreviewDragOver, TopWindow_DragOver.

In summary, I create the adorner once, the first time it is needed. I remove the adorner every time the mouse leaves the window and recreate it when the mouse re-enters the window. And I remove the adorner again at the end of the drag-and-drop operation.

Insertion Adorner

The insertion adorner is responsible for the visual feedback that indicates the insertion point of a dropped data item. For example, if you drag a data item over a ListBox, you will see a line between two of the items indicating the position where the dragged item will be inserted if dropped. The visual appearance of an insertion adorner is a line with two triangles facing inwards at the ends:

In order to make this adorner as performant as possible, I wrote a static constructor where I create a triangle and freeze all Freezable objects involved in its creation:

    static InsertionAdorner()
    {
        pen = new Pen { Brush = Brushes.Gray, Thickness = 2 };
        pen.Freeze();

        LineSegment firstLine = new LineSegment(new Point(0, -5), false);
        firstLine.Freeze();
        LineSegment secondLine = new LineSegment(new Point(0, 5), false);
        secondLine.Freeze();

        PathFigure figure = new PathFigure { StartPoint = new Point(5, 0) };
        figure.Segments.Add(firstLine);
        figure.Segments.Add(secondLine);
        figure.Freeze();

        triangle = new PathGeometry();
        triangle.Figures.Add(figure);
        triangle.Freeze();
    }

I need two triangles in this adorner. Because their positions and orientations vary according to the ItemsControl’s layout, I created just one triangle object and draw it twice after applying the appropriate translate and rotate transforms. The method below is called twice with different parameters:

    private void DrawTriangle(DrawingContext drawingContext, Point origin, double angle)
    {
        drawingContext.PushTransform(new TranslateTransform(origin.X, origin.Y));
        drawingContext.PushTransform(new RotateTransform(angle));

        drawingContext.DrawGeometry(pen.Brush, null, triangle);

        drawingContext.Pop();
        drawingContext.Pop();
    }

Next I will explain briefly when this adorner is created, removed, and updated.

The InsertionAdorner is created:

Every time the cursor enters a new element in the target’s tree. It needs to be created this frequently because different elements can have different sizes DropTarget_PreviewDragEnter.

The InsertionAdorner is removed:

Every time the cursor leaves the current element or the item is dropped DropTarget_PreviewDragLeave, DropTarget_PreviewDrop.

The InsertionAdorner is updated:

Every time the cursor moves over the drop target DropTarget_PreviewDragOver.

Windows events

The fact that I’m providing handlers for the window’s drag drop events may seem a little strange at first.

Imagine I provide handlers for the ItemsControl drop target only. Since I have code in these handlers that displays the preview adorner (which is where DragDropTemplate gets applied), the preview would only come up when the mouse cursor enters the drop target. Anywhere else in the window, the mouse cursor would turn into a crossed circle, indicating that it’s not an allowed drop location.

I like the crossed circle to come up in those areas, but I would like the adorner to be displayed anywhere I drag the item within the window.

To achieve the effect I wanted, I set the AllowDrop property of the window to true, and hooked up handlers for its drag events. I used the preview versions of the drop events for the target, but not for the window. This way, when the cursor is within the drop target I get the drop target events (and set Handled to true), but when the cursor is anywhere else in the window, I get the window’s events instead. I used these events to ensure the creation and removal of the preview dragged adorner, and to make sure that the mouse cursor is set to the crossed circle.

How can I debug WPF bindings?

Bea — Mon, 28 Jan 2008 06:02:29 +0000

Data Binding can be tricky to debug. In this post, I will share the techniques I use to debug WPF bindings, including the new debugging improvements we implemented in the latest 3.5 release. I will discuss the following four techniques:

Scanning Visual Studio’s Output window for errors.
Using Trace Sources for maximum control.
Using the new property introduced in WPF 3.5 PresentationTraceSources.TraceLevel.
Adding a breakpoint to a Converter.

The DataContext of this app is set to a new instance of Star, which is a class that contains two properties: Picture and Caption. Picture is of type BitmapImage and contains an image of the sun, which I included in the project. Caption is a string property that takes a while to be initialized (more details about this later).

Output Window

In the XAML of this application, I have an Image whose Source is data bound to an incorrect property name. This is a simple scenario that causes a Binding to fail.

Every time a Binding fails, the binding engine prints an informative message in the Output window of Visual Studio. In this case, I get the following message:

System.Windows.Data Error: 35 : BindingExpression path error: ‘PictureWrong’ property not found on ‘object’ ”Star’ (HashCode=49535530)’. BindingExpression:Path=PictureWrong; DataItem=’Star’ (HashCode=49535530); target element is ‘Image’ (Name=”); target property is ‘Source’ (type ‘ImageSource’)

This message should give you enough information to quickly figure out the mistake in the property name.

Advantage of this technique:

It is very easy to look at the Output window, and in most cases it’s sufficient. It should be the first approach you consider when you have a problem with your bindings.

Disadvantage of this technique:

Most real world applications print so much information to the Output window that it may be hard to find the error you’re looking for.

Trace Sources

The Trace Sources solution was already around in WPF 3.0. It adds a lot more flexibility to the previous solution by allowing you to control the level of detail you care about, where you want that messages to be printed and the WPF feature you want to debug.

The Trace Sources solution relies on a config file for the configuration of its behavior – the App.config file. Here is a portion of the contents of that file:

            …


                …




                …
                                type="System.Diagnostics.TextWriterTraceListener"
                initializeData="DebugTrace.txt" />
                …

In this file, I am specifying that:

I want only messages generated in the Data subarea to be printed. If you’re trying to debug, for example, animations, you would instead add the area System.Windows.Media.Animation.
I want as much information as possible about data binding. This was done by setting the switch to All. Other possible values are Off, Error, Warning. For a complete list, look up SourceLevels in .NET Reflector.
I want the messages to be printed to an external file called DebugTrace.txt, instead of the Output Window. This file will be created in the bindebug folder for the application. If you run this application twice, the messages generated the second time will be appended to the existing messages in this file. If you don’t want this behavior, remember to delete the file before running the app.

Other pre-defined listeners allow printing to the Console (ConsoleTraceListener), or to an external file in XML format (XmlWriterTraceListener).

If you run the application with the settings above, you should find a DebugTrace.txt file in the bindebug directory. If you open it, you will see the data binding error we saw previously in the Output Window, plus four “Information” messages. These lower-priority messages are printed because I specified in the switch that I want all the information available about the bindings.

If you want to learn more about this topic, I recommend Mike Hillberg’s blog. He wrote the best article I’ve read about Trace Sources, which I use frequently as a reference.

Advantages of this technique:

It separates the debug messages you care about from the rest of the information printed in the Output window.
This solution may help you debug other areas in WPF, not just binding.
You can get lower-priority messages (such as information or warnings) that are not typically printed to the Output window.

Disadvantages of this technique:

The text file (or whatever form of output you choose) will contain debug messages about all the bindings in your application. Although this is not as much clutter as the Output window, it may still require some digging for you to find exactly the information you need.
It won’t help you in scenarios where your Binding actually succeeds, but you still don’t see what you expect in the UI. The first and second techniques I show here only help in scenarios where the Binding fails.

Before you move on, make sure you correct the Path in the Image’s Source so that these errors won’t interfere with the ones I show next.

Trace Level – new in 3.5

In order to understand this feature, let’s start by uncommenting the first TextBlock in the XAML of this application:

This TextBlock attempts to bind to Caption, a property whose value is slow to be initialized. In this case, I am simulating a slow data source by adding a Dispatcher timer to the constructor, but in reality this delay could have many different causes. Notice also that I am *not* raising a property changed notification when Caption changes value.

    public string Caption
    {
        private set
        {
            this.caption= value;
            //OnPropertyChanged("Caption");
        }
        get
        {
            return caption;
        }
    }

    public Star()
    {
        this.Picture = new BitmapImage(new Uri("Images\sun.jpg", UriKind.Relative));
        this.Caption = String.Empty;
        DispatcherTimer timer = new DispatcherTimer();
        timer.Interval = new TimeSpan(0, 0, 3);
        timer.Tick += new EventHandler(Timer_Tick);
        timer.Start();
    }

    private void Timer_Tick(object sender, EventArgs e)
    {
        this.Caption = "Sun";
    }

In this scenario, the Binding will succeed (it will bind to the initial value of empty string), but you don’t see what you expect to see in the UI. The unwanted behavior is caused by the fact that the events happen in an order different from what you expect: the Binding will be evaluated before Caption gets its real value. In this case, there are no errors in the Output window or DebugTrace.txt because the Binding succeeds.

You can use the new debugging feature in 3.5 to debug this scenario by adding the attached property PresentationTraceSources.TraceLevel to the Binding, which can be set to None, Low, Medium and High. Since PresentationTraceSource is not in the default namespace mappings for WPF, you will have to write the following XAML:

        xmlns:diagnostics="clr-namespace:System.Diagnostics;assembly=WindowsBase"
    />

If you look at the Output window, you will notice that the binding engine generated debug information for every task that may help users find problems with this particular binding:

    System.Windows.Data Warning: 47 : Created BindingExpression (hash=25209742) for Binding (hash=3888474)
    …
    System.Windows.Data Warning: 91 : BindingExpression (hash=25209742): GetValue at level 0 from Star (hash=31609076) using RuntimePropertyInfo(Caption): ‘ ‘
    System.Windows.Data Warning: 71 : BindingExpression (hash=25209742): TransferValue – got raw value ‘ ‘
    System.Windows.Data Warning: 78 : BindingExpression (hash=25209742): TransferValue – using final value ‘ ‘

In this case, we can scan the debug messages quickly to see that there were no errors, and look at the last few messages to understand that the value found at the Source was the empty string. This information will help you come to the conclusion that there is some timing issue with the scenario.

Advantages of this technique:

This feature is particularly useful when you know exactly which binding you want to find out more about, which is the most common scenario.
It allows you to know more about bindings that succeed, which many times helps you find the mistake in your logic.

Disadvantages of this technique:

If you forget to remove the property after you found the problem, it adds to the clutter of the Output Window (which adds to the time it takes to start your application in debug mode).

Converter

The last solution is extremely simple: you can simply add a no-op Converter to your binding and put a breakpoint in its Convert method. This is what this solution looks like:

    public class DebuggingConverter : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            return value; // Add the breakpoint here!!
        }

        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new NotImplementedException("This method should never be called");
        }
    }

If you run this code and set a breakpoint inside the Convert method, you can simply hover over the “value” parameter to see what is being passed from the source to the target. In this case, you will see that “value” contains an empty string. This may help you realize that the source of your binding does not have the value you thought it had.

Advantages of this technique:

It is really easy to implement. It relies on a concept that most data binding users are familiar with.
It does not depend on the Output window.
It helps you find out more about scenarios where the binding doesn’t fail.

Disadvantages to this technique:

It doesn’t provide as much information as the TraceLevel technique.
If the Binding fails early, the Converter may not be called.

Conclusion

I mentioned here techniques to debug WPF bindings using Visual Studio, however there are other tools that can help you with this process. One other tool I use frequently is Snoop, not only to debug bindings but many other aspects of my application. Mole is also useful, and has great documentation.

What technique or tool you use to debug your bindings comes down to a combination of personal preference and your specific scenario.

Here you can find the project with this code built using VS 2008 RTM.

How can I implement the Master-Detail pattern when binding to XLinq and XML?

Bea — Mon, 14 Jan 2008 04:54:30 +0000

I have explained in previous posts how to implement:

A two-level Master-Detail scenario using objects as data source here.
A three level Master-Detail scenario using objects as data source here
A three level Master-Detail scenario using ADO.NET here. The two-level version of this scenario with ADO.NET should be obvious based on the samples above.

In this post, I will explain how to implement a two and three level Master-Detail when binding to XLinq and XML.

Two level Master-Detail with XML

Here is the XML data source I used for this scenario:

            57,910,000 km (0.38 AU)
            4,880 km
            3.30e23 kg

The small and rocky planet Mercury is the closest planet to the Sun.

        …

The two level Master-Detail scenario works very similarly regardless of the data source. The following code and XAML make up the core of this scenario, when using XML as a data source:

        …

Notice that both the ListBox and ContentControl elements have the exact same empty Binding as content. This is possible because, as I explained in a previous post, the data binding engine detects that the ContentControl can not display a list of items, and grabs the current item of that list instead. This is true for every data source type.

Two level Master-Detail with XLinq

I started by creating an XElement by loading the same XML file shown above, and used it as the data source for the XLinq scenario. In my last blog post I loaded the XML in code, so this time I show how to do this in XAML, using ObjectDataProvider.

            ../../SolarSystemPlanets.xml

You can see below that the only somewhat interesting difference between the XLinq and XML scenarios is the Path of the DataContext Binding. In this scenario, we need to drill into the “Elements” property of the root XElement, in order to obtain a list of Planet elements. Since we now have a collection as the DataContext, we can use a simple empty Binding on the ListBox and ContentControl to get the Master-Detail pattern to work.

        …

Three level Master-Detail with XML

Here is the XML data source I used for this scenario :

                        Headwall
                        Fisheye
                        Jimmy’s Joker


                …


        …

The three level Master-Detail with XML is a little trickier than the two level version of the same pattern. Here is the code and XAML necessary to implement this scenario:

        …

The first ListBox simply binds to the collection of Mountains (notice the XPath in the XmlDataProvider).

The second ListBox drills into the collection of Lifts of each Mountain. This is implemented internally by executing an XPath query on the instance of the Moutains collection shown in the first ListBox, with the syntax found in the XPath property. The two collections can be kept in sync because the second collection instance is a subcollection of the first.

If you’ve seen my post on three level Master-Detail when binding to objects, you probably expect the following syntax to work for the third ListBox (a similar syntax works when binding to objects):

If you try this on the third ListBox, you might be surprised by the results. The third ListBox shows all the runs of all the lifts of the selected mountain, instead of showing all the runs of the selected lift of the selected mountain. That’s because when you use this syntax, the binding engine executes a new XPath query on the DataContext, which happens to be the collection of mountains displayed in the first list box. The XPath query can’t be executed on a collection, so the binding engine executes the query on the current item of the collection – whichever mountain is selected in the first ListBox. The result of the query is completely independent of the current selection in the second ListBox.

The only way to grab instances of items from the collection in the second ListBox is by binding to the ListBox itself. This is why the DataContext of the third ListBox is bound to the SelectedItem of the second ListBox in the working solution.

You’re probably wondering why I’m binding to the DataContext and the ItemsSource of the third ListBox, instead of using the ItemsSource property only. This is what the Binding would look like, if I used the ItemsSource only:

As I explained in my previous post, it’s actually possible (and sometimes very useful) to have a Path and XPath in the same Binding. Keep in mind, however, that whenever XPath and Path are both specified, the XPath is always executed before the Path, independently of the order in which you specify them in the Binding. We decided on this order of execution because this feature is used mostly to drill into properties of XmlElement (such as HasAttributes, InnerXml or Name). In the Master-Detail sample, we need to first get the SelectedItem (which is an XmlElement), and then execute the XPath query on it. Unfortunately there is no way for us to specify in a Binding that we want to execute the Path before the XPath. And this is the reason I had to break up the Binding into two: the part with the Path needs to be executed first so it goes in the DataContext, and the XPath needs to be executed second, so it goes in the ItemsSource.

Three level Master-Detail with XLinq

Here is the code and XAML for the XLinq version of the three level Master-Detail:

            ../../Mountains.xml




        …

Similarly to the XML scenario, the first ListBox binds to the collection of Mountain XElements directly. The second ListBox gets the Lifts collection of a particular mountain, and drills into its Elements collection. This returns all the Lift XElements for the selected mountain.

But the most interesting part of this scenario is the third ListBox. First of all, notice that I am still using ElementName to bind to the second ListBox. The reason for this is exactly the same as in the XML scenario. Notice also I am no longer splitting the Binding between the DataContext and ItemsSource. That is because we use Path to do XLinq queries, so there are no issues with precedence of Path versus XPath. As you can see, we can specify our query in a much more linear way: we first get the SeletedItem (of type XElement) from the second ListBox, then get its Runs child, and then drill into all the Run elements.

Keeping two ListBoxes in sync

There are some differences of behavior when keeping two ListBoxes in sync (as part of three level Master-Detail or in isolation) using different data sources, so I will add a few extra words on this.

In the XML three-level Master-Detail, if you select “Whistler”, then “Stevens Pass”, then “Jupiter Chair”, then “Whistler”, then “Stevens Pass” again, you will notice that “Jupiter Chair” is no longer selected (the first element of that ListBox is selected instead). This happens because every time you click on “Stevens Pass”, we execute the appropriate XPath query, and that returns a different instance of the same collection.

If you try this scenario when binding to CLR objects, ADO.NET or XLinq, you will see that previous selections in the second ListBox will be remembered. This is typically what users want, so we paid special attention to it when designing integration between WPF and XLinq.

Conclusion

When you have the option of either binding directly to the current item of the previous collection or using ElementName and SelectedItem to achieve Master-Detail, I typically advise people to bind to the current item. One reason for this is that the Master-Detail scenario is a data concept, and if possible it should be implemented by using only data concepts such as currency (SelectedItem is a concept similar to currency, but relevant to the UI only). Besides, your scenario becomes independent of the names of the ListBoxes.

However, in scenarios like the three-level Master-Detail using XML and XLinq, where there is no solution purely based on current item, in my opinion it’s perfectly OK to implement the binding on the second ListBox using ElementName and SelectedItem. This has the advantage of maintaining consistency between the second and third ListBoxes, making the XAML easier to read. In this post, I wanted to show how far you can go in Master-Detail by binding to the current item only, which is why I opted to show different styles of Bindings in the second and third ListBoxes. In my opinion, both ways are OK, so it really comes down to personal preference.

Here you can find the project with this code built using VS 2008 RTM.

How can I bind WPF elements to XLinq?

Bea — Wed, 02 Jan 2008 02:41:07 +0000

One of the main features that we shipped in .NET 3.5 is the ability to bind to XLinq directly from XAML. In this post, I will first cover the basics of this new feature, and then discuss the seven queries I added to the sample project. Please keep in mind that this blog post does not attempt to provide an introduction to XLinq. For those of you that need a quick introduction to the topic, I found this site to be a good resource.

Basics of binding to XLinq

When the XLinq and WPF teams started thinking about the integration of the two products, we quickly realized that we would need to do some work to improve our XAML scenarios in .NET 3.5. The main reason for this decision was the fact that simple XLinq queries are mostly done by calling sequences of methods on an XElement (such as .Elements() or .Descendants()) and we don’t have a good syntax to do that in XAML. (Yes, we can bind to the result of a method by using ObjectDataProvider as I explained in this post, but you can imagine how cumbersome the syntax would be if you wanted to call a method on the object returned by another method call. It would be much easier to do it in code.)

Since WPF already has a good syntax for binding to properties and subproperties, the logical solution to this problem was to add PropertyDescriptors to the XLinq DLL that expose certain key methods as if they were properties. If you are not familiar with PropertyDescriptors, I encourage you to read this article on ICustomTypeDescriptor and this one on TypeDescriptorProvider. These are the two best articles I have found on the topic. There is a precedent for this solution: we did basically the same thing to provide XAML support when binding to ADO.NET. As I described in this post , we expose the Relation names using PropertyDescriptors so that you can bind to them as if they were properties.

I want you to understand how we implemented this feature so that it doesn’t come as a surprise when I say that to bind to XLinq, you will need to use a binding’s Path (not XPath!) and the same “dot syntax” that we use to bind to subproperties.

We implemented six new PropertyDescriptors. You can find the new code added by the XLinq team in the System.Xml.XLinq.ComponentModel namespace of the System.Xml.XLinq DLL. You will see the TypeDescriptionProvider (XTypeDescriptionProvider) and a new PropertyDescriptor class for each property we expose this way (e.g., XElementAttributePropertyDescriptor). The table below shows the correspondence between the properties exposed by the PropertyDescriptors (to be used in XAML) and their equivalent XLinq code.

XAML	Code	Notes
Element[MyElementName]	.Element(”MyElementName”)
Elements[MyElementName]	.Elements(”MyElementName”)	Parameter is optional.
Attribute[MyAttributeName]	.Attribute(”MyAttributeName”)
Descendents[ElementName]	.Descendents(”ElementName”)	Parameter is optional.
Value	.Value	Special case. (I explain below.)
Xml	.ToString(SaveOptions.DisableFormatting)

The properties in the XAML column of this table are all exposed in XElement, but Value is also exposed in XAttribute. Based on the table above, you can deduce that the following XLinq code…

var query = myXElement.Attribute("MyAttribute");

…has the following equivalent in XAML (assuming that the DataContext is the XElement myElement):

However, you may be wondering why we decided to define a PropertyDescriptor for Value, given that it is already a property (and not a method) of XElement (and XAttribute). It seems that we could simply bind to XElement and dot into it, right? Well, the reason for this is that we wanted to provide change notifications for Value. If you get a particular XElement as the result of a query, bind to it, and then change its value, we want that to be reflected in the UI. By adding a PropertyDescriptor for this property, we can provide change notifications in a non-intrusive way (without having to change the XElement class).

Similarly, it is important to keep in mind that anytime you bind to properties that don’t have a corresponding PropertyDescriptor (such as Root and HasAttributes in the samples I will show below), WPF will not be notified of property changes. If those properties happen to be in the middle of a query, they break the chain of notifications.

You can use .NET reflector to look into these PropertyDescriptors and understand how I came up with the table above. For example, search for XElementXmlPropertyDescriptor, look at the GetValue method, and you will see that it returns this.element.ToString(SaveOptions.DisableFormatting).

This is all there is to this new feature. Next I will show a few samples and a comparison between the XLinq code syntax, XLinq XAML syntax, and the XPath way of doing the same query.

Samples

Here is the data source used in these samples:

            57,910,000 km (0.38 AU)
            4,880 km
            3.30e23 kg

The small and rocky planet Mercury is the closest planet to the Sun.

        …

I defined the XML in an external file, added it as a Resource, and parsed it into an XDocument with the following code:

XDocument planetsDocument = InitializeDataSource("/Planets.xml");

    private XDocument InitializeDataSource(string uriString)
    {
        StreamResourceInfo resourceInfo = Application.GetResourceStream(new Uri(uriString, UriKind.Relative));
        StreamReader reader = new StreamReader(resourceInfo.Stream);
        return XDocument.Load(reader);
    }

I also created an XmlDataProvider so that I could show queries equivalent to the XLinq ones, but using XPath:

XmlDataProvider xdp = new XmlDataProvider();
xdp.Source = new Uri("Planets.xml", UriKind.Relative);

First Planet’s Orbit

    // XLinq code
    var query2 = planetsDocument.Root.Element("Planet").Element("Orbit");
    Console.WriteLine(query2);

    // XLinq XAML


    // XPath


    // Result
    //57,910,000 km (0.38 AU)

This working sample shows how easy it is to follow the table above to translate XLinq code into XAML. Please keep in mind that the range of useful query methods supported by XLinq is far greater than the ones we decided to support. For example, you could have written this same query in the following way:

var query2 = planetsDocument.Element("SolarSystemPlanets").Element("Planet").Element("Orbit");

This can not be translated directly into XAML because the first Element(…) method is called on XDocument, and we only added the Element property descriptor for XElement.

Here are a couple of other examples of queries that produce the same result:

var query2 = planetsDocument.Root.Elements().First().Element("Orbit");
var query2 = planetsDocument.Root.Elements().ElementAt(0).Element("Orbit");

These can also not be translated into XAML because we don’t provide property descriptors for First() and ElementAt(…). So, if you have an XLinq query in code that you want to translate into XAML, you should try to first modify it to use only the methods we support. Of course, this will only work for simple queries – if you are using more advanced features of XLinq, your only option is to use code.

You may have noticed that the XmlDataProvider binding above uses both XPath and Path. This scenario is fully supported and sometimes very useful. The data binding engine will first resolve the XPath, and then it will call the OuterXml property on the resulting XmlElement. If I hadn’t called OuterXml, the query would return only the content of this element.

List of Planet Names

    // XLinq code
    var query3 = planetsDocument.Root.Elements();
    foreach (var element in query3)
    {
        Console.WriteLine(element.Attribute("Name").Value);
    }

    // XLinq XAML






        …



    // XPath






        …



    // Result
    //Mercury
    //Venus
    // …
    //Pluto

In this sample I show how to bind to a collection and how to display an attribute. Notice that in XLinq, if I only want to show the content of the attribute, I have to explicitly call its Value property. If I don’t call Value, each item in the ListBox will display something like ‘Name=”Mercury”‘. In XML, binding to the attribute @Name will give me the contents of the attribute automatically.

List of Planet Diameters

    // XLinq code
    var query4 = planetsDocument.Root.Descendants("Diameter");
    foreach (var element in query4)
    {
        Console.WriteLine(element.Value);
    }

    // XLinq XAML


    // XPath


    // Result
    //4,880 km
    //12,103.6 km
    // …
    //2274 km

I added this sample to show binding to the “Descendants” property, and the corresponding XML. Pretty simple.

Non-formatted XML

    // XLinq code
    var query5 = planetsDocument.Root.Element("Planet").ToString(SaveOptions.DisableFormatting);
    Console.WriteLine(query5);

    // XLinq XAML


    // XPath


    // Result
    // 57,910,000 km (0.38 AU)4,880 km3.30e23 kg

The small and rocky planet Mercury is the closest planet to the Sun.

The Xml property allows you to query for the unformatted version of the XML. This is the only property whose name is quite different from the corresponding method in code (as you can imagine, it would be quite cumbersome to keep them consistent). If you use the same XLinq query in XAML but without “.Xml” in the Path, you would get XML that is formatted with indentation.

HasAttributes of Mass

    // XLinq code
    var query6 = planetsDocument.Root.Element("Planet").Element("Mass").HasAttributes;
    Console.WriteLine(query6);

    // XLinq XAML


    // XPath


    // Result
    // false

HasAttributes is a property that exists both in XmlElement and XElement. You can see in this example that since XLinq uses Path, it’s easy to bind to properties exposed directly in XElement. This same scenario using XPath has to be implemented by combining XPath and Path.

First Planet’s Details

    // XLinq code
    XNamespace ns = "http://myNamespace";
    var query7 = planetsDocument.Root.Element("Planet").Element(ns + "Details").Value;
    Console.WriteLine(query7);

    // XLinq XAML


    // XPath


    // Result
    //The small and rocky planet Mercury is the closest planet to the Sun.

This sample shows how to embed namespaces in XAML. Below you can see that when I instantiated the XmlDataProvider, I also added an XmlNamespaceMapping that allows me to use the string “mn” instead of the full namespace. That is how the data binding engine knows how to resolve the namespace in “mn:Details” correctly.

    XmlDataProvider xdp = new XmlDataProvider();
    xdp.Source = new Uri("Planets.xml", UriKind.Relative);
    XmlNamespaceMapping mapping = new XmlNamespaceMapping("mn", new Uri("http://myNamespace"));
    XmlNamespaceMappingCollection mappingCollection = new XmlNamespaceMappingCollection();
    mappingCollection.Add(mapping);
    xdp.XmlNamespaceManager = mappingCollection;

In XLinq, however, there is no concept of namespace prefixes. This decision was made in order to avoid confusion caused by the fact that prefixes depend on context to have meaning. For this reason, we need to include the full namespace directly in the XAML query as I show above. See what the XLinq team has to say about namespaces and prefixes.

First Planet’s info

    // XLinq code
    var query8 = planetsDocument.Root.Element("Planet").Elements();
    foreach (var element in query8)
    {
        Console.WriteLine(element.Value);
    }

    // XLinq XAML


            …

        …



    // XPath


            …

        …



    // Result
    //57,910,000 km (0.38 AU)
    //4,880 km
    //3.30e23 kg
    //The small and rocky planet Mercury is the closest planet to the Sun.

In the previous sample, you may have noticed that XLinq namespaces are surrounded by curly braces in XAML. This worked well when used inside of an indexer, however, since curly braces already have meaning for the XAML parser, sometimes we need to escape them. For example, in the DataType of the Details DataTemplate in this sample, I had to escape the namespace with a leading {}. Remember that when binding to objects, the DataType property could be set to a value such as {x:Type local:MyDataObject}, so escaping the namespace allows the parser to distinguish between the two scenarios.

Here you can find the project with this code built using VS 2008 RTM.

How can I replace PowerPoint with WPF in my presentations?

Bea — Mon, 26 Nov 2007 05:51:56 +0000

If you’ve attended one of my presentations before, you’ve noticed that I never use PowerPoint – instead, I have my slides coded in WPF. I’ve decided to write my own presentation code because I want my slides to be interactive – instead of showing a concept in PowerPoint and switching to VS to demo it, I can demo it directly within the presentation. Several people have asked me for my presentation code in the past, so I’ve decided to share it here in my blog.

Use this project

You don’t have to read the whole blog post if all you want to do is use my code as a base for your presentation. Here are the steps to add your slides to this project:

You may want to delete the pages I created (01Title.xaml, 02Slide.xaml, 03Slide.xaml).
Add a new WPF Page for each new slide you want to create.
In the “Presentation.cs” file, add the name of your xaml slide to the “slides” string array, in the order you want them to appear.

Understand the code

Yeah, I thought all of you geeks would continue reading. I will explain below how I implemented each of the features in this project.

Navigation

I added two elements to the Window’s main grid:

A frame that displays each slide in turn. Notice that its Source is data bound to the CurrentSlide property of a data source. The CurrentSlide property will contain the name of the XAML Page that is being displayed. I will show what that data source looks like later in this section.
A TextBlock that contains the title of the slide. Notice that this TextBlock is data bound to the Title of the Frame’s content (which is really the Title of each slide Page).

These two elements are wrapped by a Viewbox. I find the Viewbox quite handy in this scenario because I want my slides to scale correctly for every screen resolution.

        …

The data source that contains the slide information contains a private array with the names of the slides, and it exposes public properties for CurrentSlide and CurrentIndex.

private string[] slides = { "01Title.xaml", "02Slide.xaml", "03Slide.xaml" };

In the XAML above, you can see that I disabled the usual frame navigation UI by setting NavigationUIVisibility to Hidden. Instead, I decided to add custom “previous” and “next” buttons in the shape of arrows. I designed the arrows in Blend, added IsMouseOver, IsPressed and IsEnabled triggers that cause changes in their appearance, and used those assets within the style of my “previous” and “next” buttons. I added GoBack() and GoNext() methods to the data source that decrement and increment the CurrentIndex, and made sure that those are called in the click handlers of the arrow buttons.

Last, I wanted to disable the “next” button upon reaching the end of the presentation, and disable the “previous” button at the start of the presentation. To do this, I added CanGoBack and CanGoNext properties to my data source, to which I bound the IsEnabled property of the arrow buttons:

    public bool CanGoBack
    {
        get { return this.currentIndex > 0; }
    }

    public bool CanGoNext
    {
        get { return this.currentIndex < this.slides.Length – 1; }
    }

Are there any tricks that will help me improve TreeView’s performance? – Part III

Bea — Sat, 22 Sep 2007 19:06:33 +0000

Update: This post is out of date. With .NET 3.5 SP1, TreeView now provides opt-in UI virtualization. You can see this feature working by setting VirtualizingStackPanel.IsVirtualizing=”True” on the TreeView itself. TreeView also supports container recycling, which you can control by setting the VirtualizingStackPanel.VirtualizationMode property.

In part I of my discussions on TreeView performance, I presented the three main limitations in the current implementation of TreeView that may lead to slower performance:

UI elements stay in memory even when collapsed.
There is no UI virtualization.
There is no data virtualization.

In part II, I talked about a solution where I introduced a middle tier between the UI and the data layer, that discards the data when a TreeViewItem is collapsed, and brings the data back into memory when a TreeViewItem is expanded. This solution completely fixes the first limitation of TreeView – the UI elements no longer stay in memory after expanding and collapsing a TreeViewItem. It also partially fixes the lack of data virtualization in TreeView because we only keep a small portion of the data in memory. I say “partially” because it virtualizes data on expand/collapse, but it does not take scrolling into account.

Today I will discuss a solution that builds on top of the previous one by providing UI virtualization.

With the current version of WPF, only two Controls offer UI virtualization: ListBox and ListView (actually, ListView gets it for free because it derives from ListBox). The work to make virtualization happen is done by VirtualizingStackPanel, which is the panel used by default in ListBox. It would be nice if we could simply tell TreeView to use a VirtualizingStackPanel to lay out its items, but unfortunately it’s not that simple. VirtualizingStackPanel understands only flat lists of items, so it is not capable of laying out the hierarchical data required for a TreeView.

On the other hand, styles and templates are among the most powerful features of WPF because they allow you to completely change the look of a control while retaining its behavior. For example, this post shows how a ListBox can easily be customized to look like a diagram of our solar system. With this in mind, Ben Carter (an awesome dev on the WPF team) had the brilliant idea of simply making a ListBox look like a TreeView. This allows us to use VirtualizingStackPanel for free, which offers UI virtualization. And you will see how easy it is to make a ListBox look like a TreeView, thanks to the power of styles and templates in WPF. We’ll need to make a few changes to the data side, but I will explain what they are.

I started by thinking about the theming portion of this scenario. To make my ListBox look like a TreeView, I need the toggle button that expands and collapses TreeViewItems. I used Blend, once again, to dig into the default style for the ToggleButton in TreeViewItem (which in the Aero theme looks like a triangle), and copied it to the window’s resources. This style contains triggers to change its look when the mouse is over it, and to rotate it when a user clicks on it. Then I added the following DataTemplate to the ItemTemplate property of my ListBox:

    …








    …

I tested it with a rudimentary data source – a simple (non-hierarchical) ObservableCollection of RegistryKey items that contain a ShortName property. This helped me understand how I need my data to be presented to the ListBox.

Adding and removing items in the ObservableCollection

My first realization was that my data source can not be hierarchical this time, because ListBox only understands flat lists of data. So I will need to have a single ObservableCollection with the data for all the visible items, regardless of their depth in the original hierarchy. I will have to update this list of visible items any time the user expands or collapses an item. When the user expands an item, I will insert the item’s children just after it in the ObservableCollection. When the user collapses an item, I will remove its children from the ObservableCollection. Here is the code I wrote to make this happen:

    public class RegistryData3 : INotifyPropertyChanged
    {
        private ObservableCollection allKeys;
        …

        public ObservableCollection AllKeys
        {
            get { return allKeys; }
        }

        …
        public RegistryData3()
        {
            this.allKeys = new ObservableCollection();
            this.AddNewKeyHolder(Registry.CurrentUser);
            this.AddNewKeyHolder(Registry.CurrentConfig);
            …
        }

        private void AddNewKeyHolder(RegistryKey registryKey)
        {
            RegistryKeyHolder3 newKeyHolder = new RegistryKeyHolder3(registryKey, 0);
            newKeyHolder.PropertyChanged += new PropertyChangedEventHandler(KeyHolder_PropertyChanged);
            this.allKeys.Add(newKeyHolder);
        }

        public void PopulateSubKeys(RegistryKeyHolder3 parentKeyHolder)
        {
            int indexParentKey = this.allKeys.IndexOf(parentKeyHolder);
            if (indexParentKey == this.allKeys.Count – 1 || this.allKeys[indexParentKey + 1].Level <= parentKeyHolder.Level)
            {
                string[] subKeyNames = parentKeyHolder.Key.GetSubKeyNames();
                for (int i = 0; i < subKeyNames.Length; i++)
                {
                    RegistryKeyHolder3 childKeyHolder = new RegistryKeyHolder3(parentKeyHolder.Key.OpenSubKey(subKeyNames[i]), parentKeyHolder.Level + 1);
                    childKeyHolder.PropertyChanged += new PropertyChangedEventHandler(KeyHolder_PropertyChanged);
                    allKeys.Insert(indexParentKey + i + 1, childKeyHolder);
                    …
                }
            }
        }
        …

        public void ClearSubKeys(RegistryKeyHolder3 parentKeyHolder)
        {
            int indexToRemove = this.allKeys.IndexOf(parentKeyHolder) + 1;
            while ((indexToRemove < this.allKeys.Count) && (this.allKeys[indexToRemove].Level > parentKeyHolder.Level))
            {
                this.allKeys.RemoveAt(indexToRemove);
                …
            }
        }

        …
    }

The PopulateSubKeys method is responsible for adding an item’s children to the ObservableCollection when the user expands that item. This method retrieves the children of the parent item, creates a RegistryKeyHolder3 instance for each item and inserts those instances starting at the index just after the parent. Don’t worry about the Level concept you see in this code; I will explain it in the next section. I will also explain and show the code for the property changed event handler later in this post.

The ClearSubKeys method removes an item’s children from the list, and is called when the user collapses the parent. It starts removing items from the list in the index after the parent’s and continues until the expected number of items has been removed.

These two methods allow us to keep a flat list with the items in the order we want the ListBox to display them. Adding items to and removing items from the flat list achieves partial data virtualization, just like the solution in my previous post.

Indentation

I also realized that I need to tag each RegistryKeyHolder3 data item with the level they belong to, which will help me figure out how much they have to be indented in the ListBox. I decided to add a property called “Level” to the RegistryKeyHolder3 class for that purpose. For the root keys the Level property will be set to 0, for the next level it will be set to 1, and so on. Notice that while constructing the children key holders, the code in PopulateSubKeys specifies that the level of the children is the parent’s level incremented by 1. Also, in the ClearSubKeys method, one of the conditions to stop removing children is encountering an item that has the same level as the one being collapsed.

To indent the items in the UI based on the Level value, I added a Border to the left of the expander and text and bound its Width property to the Level property in the source:

    …







            …


    …

In order to convert a Level value to the Border’s Width, I defined the following converter:

    public class ConvertLevelToIndent : IValueConverter
    {
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            return (int)value * 16;
        }

        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new NotSupportedException("Not supported – ConvertBack should never be called in a OneWay Binding.");
        }
    }

Parent item expansion

I decided to add an “IsExpanded” property to the RegistryKeyHolder3 class that will help me tie the children expansion on the data side with the visual rotation of the toggle button in the UI.

    …







            …


    …

If you take a look at the ToggleButton’s XAML, you will notice that its IsChecked property is bound to the IsExpanded property. The Mode of this binding is TwoWay – no Mode is defined explicitly, but I know that’s the default Mode for the IsChecked DP.

Also, if you look at the code that adds items to the list in the PopulateSubKeys method, you will notice that I added KeyHolder_PropertyChanged as the handler for the PropertyChanged event on RegistryKeyHolder3. Here is the code for that event handler:

    void KeyHolder_PropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == "IsExpanded")
        {
            RegistryKeyHolder3 keyHolder = (RegistryKeyHolder3)sender;
            if (keyHolder.IsExpanded)
            {
                this.PopulateSubKeys(keyHolder);
            }
            else
            {
                this.ClearSubKeys(keyHolder);
            }
        }
    }

When the application starts, all the items appear collapsed because the IsExpanded property of each data item is initialized to false, and the IsChecked property is bound to IsExpanded. Here is what happens when the user expands an item:

1) When the user clicks on the ToggleButton to expand an item, IsChecked becomes true, and because of the TwoWay binding, the IsExpanded property for the corresponding data item is set to true.

2) RegistryKeyHolder3 raises a PropertyChanged event when its IsExpanded property changes, causing the code in the handler (the KeyHolder_PropertyChanged method in RegistryData3) to be executed.

3) Because IsExpanded is true for this data item, the PopulateSubKeys method on RegistryData3 is called, causing the children of this item to be added to the list and displayed in the ListBox.

You can imagine a similar sequence of events when the user clicks to collapse an item.

Visibility of the expander

Lastly, I wanted to make the expander for a particular item hidden whenever that item has no children. I was able to do this by adding a simple DataTrigger that causes the ToggleButton to be hidden whenever the Key’s SubKeyCount property is zero, and visible otherwise. You can see the complete XAML for the ItemTemplate’s DataTemplate here:

    …














    …

Conclusion

This solution provides true UI virtualization, as you can see in the screenshot below, where I expanded the three first items (in depth first order). If you scroll the third TreeView (or should I say ListBox?), you will see that for a little while the number of UI elements in memory increases, but it quickly settles on a number much lower than the other two TreeViews. This delay happens because we queue in the dispatcher the operation to clean up those items with a low priority so that it doesn’t make the UI unresponsive.

And just like the solution in my previous post, this solution discards children elements on collapse and provides a partial data virtualization solution.

So, should you all switch your TreeViews to ListBoxes? Well, as with almost everything in life, there is a price to pay for the benefits of this solution: the programming model is more cumbersome than if you were using a TreeView. You will not be able to use HierarchicalDataTemplates to style your items, you’ll miss the convenience properties and methods of TreeView, you’ll have to introduce a slightly complex intermediate layer between your UI and your data, and you will have to work hard to minimize the inconsistencies in the UI. In short, you can make a ListBox look like a TreeView, but you can’t make a ListBox become a TreeView.

Whether this solution is right for you depends on how much you value the performance gain over the disadvantages it brings.

Here you can find the project with this code built using VS 2008 RTM.

Bea Stollnitz

New look

How can I expand items in a TreeView? – Part III

WPF

Silverlight

Which TreeView expansion solution should I use?

Solution 1 – Expand all TreeViewItems using an implicit style

Solution 2 – Expand, collapse and select TreeViewItems using an intermediate data source

Solution 3 – Expand, collapse and select TreeViewItems using the Dispatcher

How can I expand items in a TreeView? – Part II

WPF

Silverlight

How can I expand items in a TreeView? – Part I

Expanding items in a TreeView

WPF

Silverlight

ImplicitStyleManager

Auto

OneTime

None

How can I drag and drop items between data bound ItemsControls?

Use this code

Features

Limitations

Overview

ItemsControl Drag Source

ItemsControl Drop Target

Dragging and dropping data

Dragged Adorner

Insertion Adorner

Windows events

Other similar solutions available

How can I debug WPF bindings?

Output Window

Trace Sources

Trace Level – new in 3.5

Converter

Conclusion

How can I implement the Master-Detail pattern when binding to XLinq and XML?

Two level Master-Detail with XML

Two level Master-Detail with XLinq

Three level Master-Detail with XML

Three level Master-Detail with XLinq

Keeping two ListBoxes in sync

Conclusion

How can I bind WPF elements to XLinq?

Basics of binding to XLinq

Samples

First Planet’s Orbit

List of Planet Names

List of Planet Diameters

Non-formatted XML

HasAttributes of Mass

First Planet’s Details

First Planet’s info

How can I replace PowerPoint with WPF in my presentations?

Use this project

Understand the code

Navigation

Pick starting slide

Hide cursor

Animation when clicking

Keyboard shortcuts

Conclusion

Are there any tricks that will help me improve TreeView’s performance? – Part III

Adding and removing items in the ObservableCollection

Indentation

Parent item expansion

Visibility of the expander

Conclusion