In my XAML i bind directly to the treeview's CheckState with my business object, like so:
See attached screenshot. When bound to my observable collection it all works well (on, off, inderminate), but if I expand Toplevel2 and check Cat1 the checked event is fired only for Cat1 and not it's children. If I expand Cat1 first and then check it, all three items have their checked event fired. If I remove the bindingscollection the treeview behaves as expected - both when Cat1 is expanded or collapsed (all three items fire their event). Is this intended behaviour? It seems a little odd to me and I don't want to manually code if I don't have to.
<telerik:ContainerBindingCollection x:Name="BindingsCollection"> <telerik:ContainerBinding PropertyName="CheckState" Binding="{Binding ToggleState, Mode=TwoWay}"/> </telerik:ContainerBindingCollection> <telerik:RadTreeView x:Name="RadTreeView1" Checked="CheckBoxChecked" Unchecked="CheckBoxChecked" ItemsOptionListType="CheckList" IsOptionElementsEnabled="True" IsDragDropEnabled="False" SelectionMode="Single" IsTriStateMode="True" IsEditable="False" BorderThickness="1" telerik:AnimationManager.IsAnimationEnabled="False"> <telerik:RadTreeView.ItemTemplate> <telerik:HierarchicalDataTemplate ItemsSource="{Binding ChildItems}" telerik:ContainerBinding.ContainerBindings="{StaticResource BindingsCollection}"> <Grid> <TextBlock Text="{Binding name}" ToolTipService.ToolTip="{Binding description}"/> </Grid> </telerik:HierarchicalDataTemplate> </telerik:RadTreeView.ItemTemplate> </telerik:RadTreeView> See attached screenshot. When bound to my observable collection it all works well (on, off, inderminate), but if I expand Toplevel2 and check Cat1 the checked event is fired only for Cat1 and not it's children. If I expand Cat1 first and then check it, all three items have their checked event fired. If I remove the bindingscollection the treeview behaves as expected - both when Cat1 is expanded or collapsed (all three items fire their event). Is this intended behaviour? It seems a little odd to me and I don't want to manually code if I don't have to.
2 Answers, 1 is accepted
0
Accepted
Hello Jorn,
Yes you are right. The tree view is working just as you described it. And yes, this is intended behavior.
Although it may seem little strange there is a reason we take into consideration when implemented the behavior. First, you can notice that if you check/uncheck a particular node, the Checked/Unchecked events for respective children are fired after the parent is expanded for first time. This is because the children are not created until the parent is expanded. So taking in mind that there are no created children in time of the check/uncheck we need to remember these items should be checked when they are realized(created). So everything is working fine when you don't have binding.
But when you have a data binding things are little bit different. Upon child creation the code is checking if there is data binding and takes the value from there. So when the children are created the value comes from the data binding. Put in other way, the binding have greater priority over the build it tri-state functionality.
There are several reasons to choose the binding to override default tri-state behavior:
1. You can define your custom check/uncheck propagation logic that could conflict the tri-state. And you should be able to customize the behavior of the tree view.
2. You already payed the price of storing checked/unchecked information in your view model. So there is no need to store that info into the tree internal cache again.
I hope the above explanation is useful to you. Please let us know if you need more help.
Best wishes,
Hristo Milyakov
the Telerik team
Yes you are right. The tree view is working just as you described it. And yes, this is intended behavior.
Although it may seem little strange there is a reason we take into consideration when implemented the behavior. First, you can notice that if you check/uncheck a particular node, the Checked/Unchecked events for respective children are fired after the parent is expanded for first time. This is because the children are not created until the parent is expanded. So taking in mind that there are no created children in time of the check/uncheck we need to remember these items should be checked when they are realized(created). So everything is working fine when you don't have binding.
But when you have a data binding things are little bit different. Upon child creation the code is checking if there is data binding and takes the value from there. So when the children are created the value comes from the data binding. Put in other way, the binding have greater priority over the build it tri-state functionality.
There are several reasons to choose the binding to override default tri-state behavior:
1. You can define your custom check/uncheck propagation logic that could conflict the tri-state. And you should be able to customize the behavior of the tree view.
2. You already payed the price of storing checked/unchecked information in your view model. So there is no need to store that info into the tree internal cache again.
I hope the above explanation is useful to you. Please let us know if you need more help.
Best wishes,
Hristo Milyakov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
0
Trude
Top achievements
Rank 2
Rank 2
answered on 08 Sep 2010, 10:07 AM
Yes, your explanation is useful. It's good to know the internal workings/priorities instead of guessing - that way we can take proper action. We have found a way with a bit more code.