Silverlight Controls and Silverlight Toolkit

Toolkit treeview questions

Apologies if this seems lame, coming to this from a Win32/C++ background the terrain is a little unfamiliar (1).

I'd like to be able to use the Treeview and friends to display some multi-column data in a hierarchical fashion. Very similar to a threaded email display. So if I can do this with the new TreeView, how do I do it? (2)

Here's some guessing:

1. Derive a new class from TreeViewItem, let's call it GridTreeNode.

2. Have a String[] or similiar to store content

3. Add multiple GridTreeNode instances like this:

_tree.Items.Add(new GridTreeNode("Root","11/11/1918"));

4. At some point the item is going to get displayed - does it get asked for its content, or does it get told to display it?

Finally is it possible to have a listview style header within the stock tree view?

Thx++,

Jerry

(1) - lots of scope for an informed article for the longer haried, shorter sighted API/MFC programmers out there. Where is WM_PAINT when I want it?

(2) XAML examples are OK but programmatic examples would be better. A vastly superior choice would be to show the analogue of the XAML code in C# simplifying the task of creating a new runtime experience.

(3) - some of the TreeView naming is bizarre - one of the examples chez dwahlin has this:

 <controls:TreeViewItem Header="ACME Corporation Employees">

Now surely the property should be called Text?

Re: Toolkit treeview questions

Hi Jerry,

Thanks for coping out about not being a native-WPFer. Now I need you to take one more step and admit that there's some learning curve in Silverlight/WPF before accomplishing more tasks.

The main point you're missing is the Silverlight/WPF content model. The "shouldn't Header be text?" question is a wonderful example. WPF/Silverlight doesn't have very few places that are UI oriented with string-only display. That's because we like putting "elements" in other "elements".

So, Button doesn't have a "Button.Text" property, it has a "Button.Content" property so we could put a whatever in it, not just text.
Same goes for, "Label.Content" and "TreeViewItem.Header" and "ComboBoxItem.Content" and etc.

So, the first thing you need to catch up on is - the content model. These resources might be a good start:
http://silverlight.net/learn/learnvideo.aspx?video=82688
http://learnwpf.com/Posts/Post.aspx?postId=25343042-3ab8-4a36-b9f3-00433f4fd049
http://dotnet.org.za/rudi/archive/2008/04/07/why-wpf-rock-the-content-model.aspx

Now, if you find those a bit diffecult to follow (and it's a lot to take in) you might want to spend some time brushing up on general silverlight skills at http://silverlight.net/GetStarted.

Now, with the content model - there's no need to go around massivly subclassing stuff when changing UI, only when chaging behavior.

Since all you need is changing UI for you custom whatever TreeView, you don't need to subclass anything.
And we'll use some SIlverlight DataBinding and Templating magic to achieve that.

Let's start off from this simple CLR email class:

        public 
class Email
        {
            public Email(string Title,
DateTime Date)
            {
                this.Title = Title;
                this.Date = Date;
            }
            public 
string Title { get; 
set; }
            public 
DateTime Date { get; 
set; }
        }

Next, we'll create a list of Emails.

new 
List<Email>()
{
    new Email("Hello Email",
DateTime.Now),
    new Email("Hello World",
DateTime.Now.AddDays(1)),
    new Email("foo",
DateTime.Now.AddMinutes(30)),
    new Email("bar",
DateTime.Now.AddYears(1)),
};

And place those inside our TreeView.ItemsSource (Some of the Silverlight item templating magic...)

trvEmails.ItemsSource = new
List<Email>()
                {
                   new Email("Hello Email",
DateTime.Now), 
                   new Email("Hello World",
DateTime.Now.AddDays(1)), 
                   new Email("foo",
DateTime.Now.AddMinutes(30)), 
                   new Email("bar",
DateTime.Now.AddYears(1)), 
                };

now, let's add our TreeView:

    <controls:TreeView x:Name="trvEmails"
 Height="150" Width="142"
                      ItemTemplate="{StaticResource HelloWorldTemplate}"/>

And lastly we'll add the ItemTemplate we'll generate:

     <UserControl.Resources>
         
<DataTemplate x:Key="HelloWorldTemplate">
            <StackPanel Orientation="Vertical">
                <controls:Label Content="{Binding
 Title}"/>
                <controls:Label Foreground="Gray" Content="{Binding
 Date}"/>
            </StackPanel>
        </DataTemplate>
    </UserControl.Resources>

Now, if we run this sample:

Now, the next few step you'll have to take on your own. You'll need to read up on how Templating really works, how does the databinding mechanism works, and check out the HierarchicalDataTemplate TreeView uses. You can check that last part at our online samples in: http://silverlight.net/samples/sl2/toolkitcontrolsamples/run/default.html (TreeView --> Basics --> DataBinding, and you can see source if you click on the XAML file name on top)

Best of luck,

Re: Toolkit treeview questions

Hello Justin

Thanks for the quick response. Silverlight is great, I've only got a problem with the shortage of documentation, the latter not unreasonable though given the pace of development.

OK I get the data binding bit - and I can now replicate this in code. What I don't get is how to replicate the programmable functionality of the Win32 tree control for example. In my case I want to have arbitrary levels of nesting - which is not something I can specify in the XAML data template.

Question 1 then. Extending your Email class

    public class Email
    {
        public Email(string Title, DateTime Date)
        {
            this.Items = new List<Email>();
            this.Title = Title;
            this.Date = Date;
        }
        public string Title { get; set; }
        public DateTime Date { get; set; }
        public List<Email> Items { get; set; }
    }

In code I can now do this:

            trvEmails.Items.Add(new Email("Email 1", DateTime.Now));
            Email em2 = new Email("Email 2", DateTime.Now);
            trvEmails.Items.Add(em2);
            em2.Items.Add(new Email("Email 2.1", DateTime.Now));
            em2.Items.Add(new Email("Email 2.2", DateTime.Now));
            trvEmails.Items.Add(new Email("Email 3", DateTime.Now));

but it is really unclear who manages the hierarchy. Is it the TreeView, the TreeViewItem or the class that is contained within the item.

Question 2 is then this:

If I have added em2 to the trvEmails, how do I find it in the tree? Use case: a new email arrives which is a response to email 3. I need to find it and add the reply as a child item. Do I need to maintain my own map/dictionary of Email instances or does the control do this for me?

Your help much appreciated.

One quibble:

So, Button doesn't have a "Button.Text" property, it has a "Button.Content" property so we could put a whatever in it, not just text.
Same goes for, "Label.Content" and "TreeViewItem.Header" and "ComboBoxItem.Content" and etc.

Can you spot the naming inconsistency here? No biggie.

Re: Re: Toolkit treeview questions

you should use HierarchicalDataTemplate to get nesting

Re: Re: Toolkit treeview questions

Thanks but how do I achieve that in code? A really simple example is all I'm after.

ATB

Jerry

Re: Re: Re: Toolkit treeview questions

I think the logical leap you may be missing, Jerry, is that you don't manually add the items to the treeview in code at all.

You specify in the HierarchicalDataTemplate what the source of the data is using the ItemsSource property, which should behind the scenes be an ObservableCollection of your type Email. The runtime will automatically create the items for you.

The toolkit download does have good examples in it of what you are seeking, try the NestedHierarchicalDataTemplate example.

Re: Re: Re: Toolkit treeview questions

Hello Anye

Thanks for the comments. I don't think it quite addresses the right issue however*

Questions arising:

1. How do you specify an potentially unbounded (but practically limited) hierarchy in a XAML data template? I cannot work that out from the Hierarchical sample which seems to me to have a very definite, hard-coded, nesting depth of 3 items.

2. How is the hierarchy managed? Consider the ultra simple example of a set of nested folders. If I want to display the folder tree, which will change at runtime depending on the root item I specifiy, how do I display the hierachy.

These are not hard questions - the use of XAML in the examples is cute but not comprehensive. XAML does not remove the need for code - yet!

ATB

Jerry

* Adding items directly to the tree or to a collection is immaterial from a philosophical point of view - somewhere, ultimately, there must be a container

Re: Re: Re: Re: Toolkit treeview questions

Jerry,

if you look at the sample at http://leeontech.wordpress.com/2008/10/30/changing-treeview-template/, you will see the decleration of HierarchicalDataTemplate

<controls:HierarchicalDataTemplate x:Key=”dtTeam”>
            <TextBlock Text=”{Binding Name}” />
        </controls:HierarchicalDataTemplate>
        <controls:HierarchicalDataTemplate x:Key=”dtDivision”
                                           ItemsSource=”{Binding Path=Teams}”
                                           ItemTemplate=”{StaticResource dtTeam}”>
            <TextBlock Text=”{Binding Name}” />

        </controls:HierarchicalDataTemplate>
        <controls:HierarchicalDataTemplate x:Key=”dtLeague”
                                           ItemsSource=”{Binding Divisions}”
                                           ItemTemplate=”{StaticResource dtDivision}”>
            <TextBlock Text=”{Binding Name}” />
        </controls:HierarchicalDataTemplate>

In that sample, I had Hierarchy of Leagues->Divisions->Teams

we can do this only to predetermined levels. In WPF we could specify the template to be applied based on datatype which can allow us to build a tree to nlevels(which are not known). I dont think we can do that in Silverlight unless I overlooked something

Re: Toolkit treeview questions

Hi Jerry,

I agree with Anye that there's a mental leap needed here to not jump straight back into code whenever you're a bit uncomfortable with XAML.

In order to make the sample work with the modified email class, you need to make 2 changes.
1. Instead of using an ItemTemplate use a HierarchicalItemTemplate.
2. Specify an ItemsSource for the nested children of that templatex.

          <controls:HierarchicalDataTemplate x:Key="HelloWorldTemplate" ItemsSource="{Binding Items}"/>
            <StackPanel Orientation="Vertical">
                <controls:Label Content="{Binding Title}"/>
                <controls:Label Foreground="Gray" Content="{Binding Date}"/>
            </StackPanel>
        </controls:HierarchicalDataTemplate>

The HierarchicalDataTemplate will call upon itself unless you specifiy an ItemsTemplate for other Templates of it's children.

When a new email is received, you do not need to manually walk the tree and add it. If you use ObservableCollection<Email> to describe the list of nested items, the TreeView UI would be updated as soon as the underlying collection changes.

Re: Toolkit treeview questions

Hello Justin

If you can do it in the mark-up then you should be able to do it in code. Not an unreasonable view I think. Practical use case? How about this:

Change your view of email from threaded by reply (potentially unlimited nesting) to 'sorted by date'.

In all of the examples posted so far you cannot do this kind of thing as the view of the data is firmly locked to the tree view control declaration in the XAML.

Let me ask this another way. How would you code a control to mimic an Explorer style view of a file system using the TreeView control?

Jerry

Re: Toolkit treeview questions

OK - here is a programmatic solution to the problem. I hope this might save someone else 3 or 4 days of experimentation.

1. The first thing is to set up a class to represent the data that is going to be viewed - the fact that this control is called a TreeView is, I think, no accident. It is quite different to a Win32/WinForms control. As my original question concerned email let's stick with that. Here is the class that we'll use.

     // this will be displayed in the Silverlight TreeView
    public class EmailItem
    {
        // constructor takes various arguments as one might expect
        public EmailItem(string Title, string From,DateTime Date)
        {
            // by default a root item so no parent
            this.Parent = null;
            // the observable collection is very important here, it means that an instance of this class
            // will get notified if the collection changes,
            // as well as the container getting notified of changes - see the Add() code later.
            this.Items = new ObservableCollection<EmailItem>();
            // this is for sanity checking and general proof of understanding
            this.Items.CollectionChanged +=
                new NotifyCollectionChangedEventHandler(Items_CollectionChanged);
            // assign the constructor parameters
            this.Title = Title;
            this.From = From;
            this.Date = Date;
        }
        // the collection has changed - just spew a debug message for the moment
        void Items_CollectionChanged(object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
        {
            if (sender != null)
            {
                Debug.WriteLine("Items_CollectionChanged: " + sender.ToString() + "(" + e.Action.ToString() + ")");
            }
        }
        // our email properties.
        public string Title { get; set; }
        public string From { get; set; }
        public DateTime Date { get; set; }
        public EmailItem Parent { get; set;} // the parent emailItem - enables us to work back up through the hierarchy
        // this is special - this collection will contain all of the
        // emails which are children in the hierachy. Imagine them to be
        // the collected replies to a specific email. The depth of the
        // hierarchy is bounded only by systems limits.
        public ObservableCollection<EmailItem> Items { get; set; }
    }

2. Now we need to tell the tree view what is it going to display. The XAML here totallly dictates the appearance of the item in the view. This XAML snippet places a tree view on the layout and determines the content. Somewhere you will need to have added a namespace to the XAML referencing the Silverlight toolkit (SLTK)

xmlns:controls="clr-namespace:Microsoft.Windows.Controls;assembly=Microsoft.Windows.Controls"

So any SLTK controls are prefixed with a controls: namespace qualifier

        <controls:TreeView Margin="8,80,102,78" x:Name="trvEmails" SelectedItemChanged="ctlTree_SelectedItemChanged">
            <controls:TreeView.ItemTemplate>
                <controls:HierarchicalDataTemplate x:Name="EmailItemTemplate" ItemsSource="{Binding Items}">
                    <StackPanel Orientation="Horizontal">
                        <controls:Label Width="80" Content="{Binding Title}"/>
                        <controls:Label Width="80" Content="{Binding From}"/>
                        <controls:Label Foreground="Gray" Content="{Binding Date}"/>
                    </StackPanel>
                </controls:HierarchicalDataTemplate>
            </controls:TreeView.ItemTemplate>

In English then, we've got a TreeView called trvEmails with an event handler called ctlTree_SelectedItemChanged that is invoked when the selection changes in the tree.

Next comes the clever/tricky bit - the ItemTemplate. This contains a HierarchicalDataTemplate declaration which has as it source binding a property called Items. This is bound directly to the Items property in the EmailItem class. Importantly Items is not directly viewable - the bits of the email message we wish to display is specified by the StackPanel. Note I've chosen to orientate this horizontally - this means we get a columnar layout for the EmailItem with the content described by the 3 labels that follow. Note that each label is bound to a separate property of the EmailItem class - in turn Title, From and Date. Just to show we are in control, the date is drawn as greyed text.

That, as they say, is that. Let's move on to the code.

3. Now if you have added the C# code and the XAML markup to a project, the tree, at runtime, will be empty. Here's some code to populate the tree:

// I've added this code to the page constructor

        public Page()
        {
            InitializeComponent();
            // add the first new email item to the root collection
            EmailItem emi = new EmailItem("Email 1","Root", DateTime.Now);
            trvEmails.Items.Add(emi);
            // add a 'reply' to the first email
            emi.Items.Add(new EmailItem("Email 1.1", "abc", DateTime.Now));
            // add another root item
            emi = new EmailItem("Email 2", "Root", DateTime.Now);
            // insert it into the view collection
            trvEmails.Items.Add(emi);
            // and add a reply to the second item
            emi.Items.Add(new EmailItem("Email 2.1", "abc",DateTime.Now));
            // finally a third root item
            trvEmails.Items.Add(new EmailItem("Email 3", "def", DateTime.Now));
}

This should be pretty self explanatory - what you get then is a tree that initially looks like this - note the arrows indicating that the item has children. Magic!

and here is the tree with the items expanded:

4. Neat. Let's code up the event handler that is called when the tree selection changes:

        private void ctlTree_SelectedItemChanged(object sender, RoutedPropertyChangedEventArgs<object> e)
        {
            Debug.WriteLine("ctlTree_SelectedItemChanged");
            EmailItem oldItem = e.OldValue as EmailItem;
            EmailItem newItem = e.NewValue as EmailItem;
            // _selectedEmailItem is declared within the class as:
            // private EmailItem _selectedEmailItem;
            _selectedEmailItem = newItem;
            // see next paragraph
            btnAdd.IsEnabled = (_selectedEmailItem != null);
            if (oldItem != null)
            {
                Debug.WriteLine("Old: " + oldItem.Title);
            }
            if (newItem != null)
            {
                EmailItem emi = newItem;
                while (emi != null)
                {
                    Debug.WriteLine("Walking back to root: " + emi.Title);
                    emi = emi.Parent;
                }
            }
        }

This handler updates an EmailItem instance (_selectedEmailItem) that is declared within the page code. This makes life a bit simpler in a moment,as I hope to show. Once we are sure we've updated the _selectedEmailItem we do a little bit more work to ensure we've actually tamed the beast and it is working as we expect. Caveat: I'm not sure this is 100% neccessary. There may be a more generic navigation mechanism built into the TreeViewItem but I've not found it yet. What we do when the selection changes is to walk back up the tree until the item under examination has a null parent - at each stage we print out the email title.

5. Now, in the case of the items we have inserted so far, we have not set the Parent property. I've skipped over it entirely This might be useful if you want to refer back to the email in your reply for example. Assume a button called btnAdd has been added to the XAML and an suitable handler added to the C# code. Here's what the handler will do:

        private void btnAdd_Click(object sender, RoutedEventArgs e)
        {
            // invariant - cannot be null if button enabled
            if (_selectedEmailItem != null)
            {
                // this new email is from jerry
                EmailItem emi = new EmailItem("re:" + _selectedEmailItem.Title,"Jerry", DateTime.Now);
                // and its parent is the current selection
                emi.Parent = _selectedEmailItem;
                // add the new child to the collection in the parent
                _selectedEmailItem.Items.Add(emi);
            }
        }

This should be adequately commented - we add a new item to the tree as a child of the current selection. What is pretty clever is that at no point is the TreeView or any TreeViewItems involved. But, despite this absence of an explicit link, the action of adding the email will ensure the view is updated, with the modified item now displaying the 'i've got child items' arrow. See green callouts.

6. Finally. That covers the essentials and answers my initial question. Hope you find this useful. Please feel free to comment/query/criticise as you see fit. I'd appreciate it if the latter was constructive in nature!

Jerry

Re: Toolkit treeview questions

Hi Jerry,

Unfortunately in Silverlight there are some things you can only do in XAML and not code. You can't currently create DataTemplates (or HierarchicalDataTemplates, etc.) in code (except for using XamlReader.Load on a string of XAML).

You can still do most of your work in code if you prefer though. The trick is to create a regular DataTemplate that defines how you like your items rendered and stick it in the Resources of a named control. Then you can look it up with DataTemplate emailTemplate = myControl.Resources["MyTemplate"] as DataTemplate;. Just create all your TreeViewItems, set the Header to be your email, and set the HeaderTemplate to be emailTemplate. You can add children directly to the TreeViewItems.Items collection. It's a little more work to set up, but you don't have to worry about whether items are in the visual tree when you construct them yourself.

Thanks,
Ted

Re: Toolkit treeview questions

Hello Ted,

Thanks for the comment. May I suggest this gets added to the samples/documentation? Is it possible to knock up a code snippet that does this with an HDataTemplate?

One thing - the problem with DataTemplates is that they violate the separation of design and code. All of a sudden I have to fill a not very easy to segment XAML document with a load of stuff that may or may not make sense to a Blend designer. A very unfortunate side effect is that you now have (effectively) duplicated class declarations, one in a C# file, the other in the XAML. It is, however, an intractable problem - after all you do have to tell the control what to display.

While you are here: what is the best way to add a column header to a multi-column tree view like I have in my screen snaps?

ATB

Jerry

Re: Re: Toolkit treeview questions

This is a nice tutorial, Jerry. Unfortunately I'm still stumped in the scenario when you only want to load the top level items upfront - you can't see the expand-o button unless there is a child node, so there is a classic chicken-and-egg problem.

Any ideas?

Re: Re: Toolkit treeview questions

Anye - to clarify then the initial situation is that your tree has 3 root items. None of these has any children but you want to populate on demand? Here is one possible solution that assumes you've something similar to my EmailItem class. So:

1. If its a root node then its parent is null - by definition.

2. If nodes are to be populated on demand then the user is going to have to indicate which node is to be loaded and displayed.

3. 2. implies you could use the selectionChanged event on the tree - so we have a couple of extra lines of code:

EmailItem emi = newItem;
// has the item got any children? There are any number of variations on this theme - one could have a loaded flag in the item for example
if (emi.Items.Count == 0)
{
    EmailItem ema = new EmailItem("re: " + emi.Title, "1.0", DateTime.Now);
    // this correctly sets up the visual state too.
    emi.Items.Add(ema);
}

Does that help? I know it means the initial nodes will not display a > until they are clicked but that is not too horrible to contemplate. You could flag this with textual or color changes.

The alternative is to modify the code and add the ability to set the visual state to 'expandable' even if the collection of child items is empty. I hope that this is one of a number of improvements that will get added to this important control - trees have become essential elements in most of the apps I write these days.

HTH + ATB

Jerry

Re: Re: Re: Toolkit treeview questions

Thanks, Jerry.. after I posted it occured to me that I could probably fiddle with the TreeView source to make the button appear even if there is no child. I think I will try that.

The reason I didn't want to just use the selectedChanged is that my TreeViewItem templates have either checkboxes or radio buttons depending on where they are being used - so I don't necessarily want them "selected" when expanding :)

Cheers,

Anye

Re: Re: Re: Toolkit treeview questions

Anye, maybe it is really easy to set the right visual state. Is not all this stuff in the XAML template?

Re: Re: Re: Toolkit treeview questions

Another option would be to Load the top level of the Hierarchy up front and then load the data needed to expand each of the top level nodes asynchrounoulsly in the background. This way once the backgound task to get the data for a given node has completed and updated the ObservableCollection for that node to have children, the ui would automatically display the Expand-o button.

If you have only a few top-level nodes with just one level of nested nodes this may be useful. You show the user the top level nodes quickly, and as the data is retrived for each of thos nodes the Expander button appears.

Re: Re: Re: Toolkit treeview questions

Hello Russ, interesting idea - have you tried this?

Re: Re: Re: Toolkit treeview questions

Yes, I have. The top level nodes display once the control is loaded, and then the 'expand-o' images start to appear one ate a time on each top level node.

I'm calling a WCF service to fill my top level. nodes. When I get the results from that call I'm looping through the results adding nodes to my ObservableCollection and also -- for each node-- calling another service to get the nodes children.

Not sure if this is the right way to do this, but it looks really cool watching the expand-o icons light up one after another going down the page :-}