Hello Manasi,

It appears that if you have the same object array property bound to one tree's SelectedDataItems property and another's ItemsSource property, it reproduces this handled exception, which appears to be happening in the property changed callback for the ItemsSource of the ItemsSource-tree. I have also seen that this same handled exception appears if you use an element-name binding to another tree's SelectedDataItems collection. For example: ItemsSource="{Binding ElementName=otherTree, Path=SelectedDataItems}".

I am still looking into this to really determine whether or not it is a bug in our code or something else, but it appears to have to do with the property changed of the ItemsSource when removing an item from another tree's SelectedDataItems collection. For your requirement, though, I would recommend using the SelectedDataItems of one tree with a separate collection that you use for your secondary tree, as described a couple of posts to this forum ago.

Please let me know if you have any other questions or concerns on this matter.

Hello Manasi,

Thank you for your response.

I have been investigating into this exception, and it appears to happen when one tree is bound to the SelectedDataItems property of another. It also appears that this exception is handled by the XamDataTree. Was this exception crashing your application on your end, or are you just seeing it appear in the Output window of Visual Studio? I am unable to reproduce a crash with the sample application you had provided, even after removal of the Try-Catch statement, which leads me to believe that this exception is handled internal to the XamDataTree. Are you seeing a behavior in which your application crashes after deselecting an item in one of the XamDataTree controls?

Please let me know if you have any other questions or concerns on this matter.

Hello Manasi,

I have been investigating into this issue a bit further, and I am able to reproduce the exception that you are seeing. This exception only appears in the output window on my end though, and it appears that it is handled internally. I will need a little bit more time to really look into what exactly is causing this exception, though, to see if it should be logged as a bug or not.

Regarding a way to find out when the NodeCheckedChanged event has finished on all nodes, there currently does not exist an event for this. When you check a parent node, it will check all of its child nodes, which, in turn will fire the NodeCheckedChanged event for each of these nodes. One thing that I can recommend on this matter is to add an EventSetter in your Style for XamDataTreeNodeControl for the XamDataTreeNodeControl.PreviewMouseLeftButtonDown event. This event will fire when a parent node is checked, but it will fire before the NodeCheckedChanged event fires for any other nodes. What this allows you to do is to keep a global XamDataTreeNode variable, and set it in the XamDataTreeNodeControl.PreviewMouseLeftButtonDown event. You can do this by casting the sender of that event to a XamDataTreeNodeControl element, and using the Node property of that element to get the actual node that it represents. Since this XamDataTreeNode will be globally accessible, you can then check the e.Node property of the NodeCheckedChanged event against your global XamDataTreeNode to see if they are equal. This will allow you to catch that event for the parent node that gets checked, and it appears that from debugging this, the parent-level node will be the last one to fire that particular NodeCheckedChanged event, so at the point of it firing for your parent node, you can make the assumption that all of the child nodes are checked.

Regarding the "duplicate" nodes in the "selected" XamDataTree, this behavior is expected, because you are binding your XamDataTree to the same collection as your other XamDataTree is using for its SelectedDataItems property. This, coupled with the fact that you are defining a NodeLayout for your "selected" XamDataTree allows that tree to essentially show the child nodes of each of the selected parent nodes, along with each of the items that actually exist within the SelectedDataItems collection of the original tree. That said, this behavior that you are seeing with the "duplicate" nodes is expected.

An issue gets raised here when you try to remove the "duplicate" nodes here, though. Since the collections that you are binding your "selected" XamDataTree and the SelectedDataItems property of the primary tree are the same one, if you start removing "duplicate" data items from this collection, you will affect the selected nodes in the primary tree as well as what is shown in the secondary one. To get around this, I would recommend that you define a collection separate from the primary XamDataTree to use as the "selected" one's ItemsSource. This collection can then use the NodeCheckedChanged / PreviewMouseLeftButtonDown events mentioned above to populate, or you can have it speak with the collection bound to the SelectedDataItems property of the primary XamDataTree so that only the parent-level nodes are actually added to the secondary tree.

I hope this helps you. Please let me know if you have any other questions or concerns on this matter.