I'm currently evaluating the XamDataTree to replace a custom WPF multi-selection Tree control. I fail to get the correct DataTemplate to be applied to my node items.
The nodes (ItemsSource) to be displayed in the XamDataTree are of a superclass that further contains a collection of child items of the same superclass, e.g:
public class ItemBase { public ItemBase() { this.Children = new ObservableCollection<ItemBase>(); }
public ObservableCollection<ItemBase> Children { get; private set; } }
and
xamDataTree.ItemsSource = new ObservableCollection<ItemBase> ();
The instances (to display) in the corresponding collections are of subclasses of ItemBase. See the attached project for a simple sample.
In the standard WPF controls, selection of datatemplate for each class is typically done with a DataTemplateSelector, but I can't find any option to use such a feature with the XamDataTree nodes.
I've played around with the 'GlobalNodeLayouts' and 'NodeLayout collections, but fail to succeed; Either the subclasses' datatemplates aren't applied at all, or only one of the templates are selected and applied to all nodes.
All samples I've seen for the XamDataTree only have single class types in e.g. their 'Children' collections. I've never seen any samples using baseclass instances as children objects. Isn't this supported by the XamDataTree framework ?
What is the proper way to set up these subclass DataTemplates ?
Regards,
Leif
Hi,
Thanks for the detailed explaination and the sample - they allowed me to clearly understand the issue you are having.
Unfortunately, what you are trying to achieve is not supported - you are trying to assign two different DataTemplate-s to a single NodeLayout.
So, for example you have two objects the following types in your ItemsSource collection:
You can specify only one DataTemplate that will be applied to the nodes for those objects.
From what I see you are trying to achieve, you should make sure your base class 'ItemBase' contains a property which you can bind to in your single DataTemplate and to return the corresponding value for your different types of objects, e.g.:
public class ItemBase { public string Name { get; set; } public ItemBase() { this.Children = new ObservableCollection<ItemBase>(); } public ObservableCollection<ItemBase> Children { get; private set; } }
<DataTemplate DataType="{x:Type local:ItemClass1}" x:Key="item1Template"> <TextBlock Text="{Binding Data.Name}" Background="LightBlue" /> </DataTemplate>
<ig:XamDataTree.GlobalNodeLayouts> <ig:NodeLayout Key="Children" TargetTypeName="ItemBase" ItemTemplate="{StaticResource item1Template}"> </ig:NodeLayout> </ig:XamDataTree.GlobalNodeLayouts>
HTH,
Thanks for the quick response. Unfortunately, the pattern to put bindable properties in the base class isn't very practical in our case (although it can be for my simple sample), since the subclasses' bindable properties varies a lot. Each subclass datatemplate e.g. have its own context menu that uses a lot of subclass-specific commands for the bindings (we use a strict MVVM design). The datatemplates need to access subclass specific data to make sense.
We must do it in another way.
Any chance of the XamDataTree NodeLayout getting support for a DataTemplateSelector through e.g. an ItemTemplateSelector property ?
Unfortunately, we currently do not support DataTemplateSelector.
BTW, DataTemplateSelector is supported in WPF only and XamDataTree is built for both Silverlight / WPF.
I am not sure if the following is applicable, but have you tried something like: http://msdn.microsoft.com/en-us/library/system.windows.datatemplate.datatype.aspx
Also, if you would like you may submit a feature request for the DataTemplateSelector at:
http://devcenter.infragistics.com/Protected/RequestFeature.aspx
Using the DataTemplate.DataType won't work in this case.
I've submitted a feature request, since I find that the flexible templating scheme provided by standard WPF controls (e.g. the WPF TreeView) should also be provided to the XamDataTree users. I hope that any decision to not support this isn't based on wanting equal API support for WPF and Silverlight. If such decisions are made throughout the library, the NetAdvantage library will end up less flexible and attractive for us non-Silverlight users.
Thanks for the feedback and taking the time to let us know about the feature request.
I personally find this feature very helpful as well and hope we will be able to provide soon (despite the fact that the control is built for the two platforms).