Hello Manasi,

I am glad that the sample project I had provided you clears things up for you.

The reason that the "SelectedMenuTree" is not being populated is because although the data tree nodes in your left-hand side XamDataTree are checked, that doesn't necessarily mean that they are selected - it only means that they are "checked". You can see this by examining the SelectedMenuItems collection that you have bound to your XamDataTree.SelectedDataItems property at runtime. On load of the XamDataTree, this collection appears to be empty. If you click on one of the nodes, it will get selected, and you should see your other tree show up correctly.

If you want the checked nodes to correspond directly to the selected nodes, I would recommend that you set the IsSelectedMemberPath property of your XamDataTree's NodeLayout to the same property that your CheckBoxMemberPath is set to. This will select the nodes in your XamDataTree as long as those nodes are checked. In the case of the sample project that exists on this forum thread, the code for this would look like the following:

  <ig:NodeLayout Key="MenuLayout"
                          TargetTypeName="clsMenuItem"
                          DisplayMemberPath="Description"
                          CheckBoxMemberPath="IsSelected"
                          IsSelectedMemberPath="IsSelected"
                          >

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.

Hello Manasi,

The definition of that style for XamDataTreeNodeControl in the XamDataTree.Resources is at a lower scope than the one defined in your Grid.Resources, so yes, this will effectively override the one in your Grid.Resources. This is not to say that you can't have both, though.

I would recommend giving the style in your Grid.Resources an x:Key. This will allow you to base the one in your XamDataTree.Resources off of the one in your Grid.Resources by using BasedOn="{StaticResource gridResourceKey}" in the <Style> tag. Note, though, that this will now remove the style from your secondary XamDataTree, as the style in the Grid.Resources will no longer be implicit. You can reapply this style to your secondary XamDataTree by setting the NodeStyle property of your NodeLayout in the secondary tree to "{StaticResource gridResourceKey}." This will allow you to have both the PreviewMouse event and the context menu on the tree that you need it on.

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

Hello Manasi,

I have taken a look at the sample project that you have attached, and the issue here is not so much the PreviewMouseLeftButtonDown event or the NodeCheckedChanged event. The reason your checkboxes are not changing their state is because you are showing a message box on the PreviewMouseLeftButtonDown event. This message box will essentially demand focus, and since the "PreviewMouse" related events actually happen before the actual mouse events, the mouse action never gets triggered, and so the node never gets checked.

After removing these message boxes from your sample, I see that the NodeCheckedChanged event now gets fired, but there is still an issue. Currently, the "SelectedCopy" collection that you are using for your separate tree is getting populated inside of the setter for the bound object array used for the first tree's SelectedDataItems property. This is going to cause issues, because you will be adding more and more nodes to the tree each time this SelectedDataItems array changes. Currently, you are also adding all of the nodes that exist in the SelectedDataItems collection, so you are getting essentially the same behavior as before, but since you are adding them each time this array changes, you will actually end up with many more nodes in your separate tree than you originally had by binding the separate one to the SelectedDataItems array of the original tree.

It appears to me that perhaps you are slightly confused on what I had meant by usage of the PreviewMouseLeftButtonDown and NodeCheckedChanged events from a couple of posts ago. In an attempt to alleviate that possible confusion, I have created a sample project that is based on the one you have sent me. Note, this sample project is very barebones, in that I have removed all of the styling and anything extra that doesn't pertain to the actual selection-based operations between the two trees. This was intentional, as the point of this sample project is to demonstrate what I had tried to describe from a couple of posts to this forum ago, without the inclusion of the extra styling clutter in the code used.

The sample project demonstrating these operations is attached. I hope it helps you.

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