I have a situation where I have 2 XamDataTrees that I need to be able to drag and drop items from one to the other.
Data structure consists of Schemas, Groups, Nodes, Leaves:
What we want to achieve with dragging:
Since the tree is particular about the type when dragging and dropping, this is proving to be a challenging problem. Deriving from a base type gets things working, but I can't disallow things like dragging a node from Tree 2 into a schema in Tree 1. This seems to be a problem of the IsDropTarget being conditional on what the drag source type is and I can't figure out how to make that happen with this control. Any help would be appreciated.
Hello Tracie,
I have been investigating into your requirement, and at the moment, none of the drag-drop related events that the XamDataTree exposes will really let you restrict drag and drop from one node to another, especially if they are all derived from a base type and the collections that make up your layout are child collections of that base type as you have mentioned.
With that said, some time ago I did derive a solution for another forum thread discussion using the IsEnabledMemberPath of the NodeLayout and the NodeDraggingStart and NodeDragEnd events so that you can disable certain underlying data items from being dragged to depending on the type that you are currently dragging. That forum thread, along with a sample project I wrote for it is located here: https://ko.infragistics.com/community/forums/f/retired-products-and-controls/105253/xamdatatree-drag-drop-within-the-parent-node. Please disregard the mentioning of the “Silverlight” XamDataTree, as the XamDataTree was a shared control between Silverlight and WPF, back when we still supported Silverlight.
By setting the underlying property that the IsEnabledMemberPath is pointed at such that some nodes will be disabled, your end user will not be able to drag to the nodes that are disabled. The same can be said from Tree 1 to Tree 2 in this case if you mark the IsEnabledMemberPath for all of the items in Tree 2 to be disabled when a node begins dragging in Tree 1. Then, you can reset the underlying IsEnabledMemberPath property in the NodeDragEnd event.
I hope this helps you. Please let me know if you have any other questions or concerns on this matter.
Hi Andrew,
Thanks for the reply.
The thread that you pointed me to isn't terribly helpful because the NodeDraggingStart event doesn't appear to know at any point what the droptarget will be. What I really need is the ability to disable the droptarget dependent on the types for both the dragsource and the droptarget.
With that said, I was able to get something kind of working through the NodeDragDrop event. I look for the type on both the dragnode and the droptarget, then set
e.DragDropEventArgs.OperationType = Infragistics.DragDrop.OperationType.DropNotAllowed; e.Handled = true;
This seems to work, the only issue at this point is the styling of the cursor as it hovers over the droptarget. It indicates that a drop should be possible, but this logic disables it. Any clues on how I can restyle the template?
That seemed to work. The drag/drop from the right tree to the left seems to work well. What I'm concerned with is the dragging within the left tree, specifically dragging a group into a group within that tree.
I have been investigating into the sample project you have provided, and it seems that the underlying reason for the issues that you are seeing is due to the Schema class’s Children collection being an ObservableCollection<Group> rather than an ObservableCollection<GroupingItem>. I am unsure if this is an option for you to change as it may break your data structure, but doing so appears to resolve the drag and drop issues you are seeing.
This is rather strange, as the Group class derives from GroupingItem, and that leads me to believe that perhaps internally we are doing something incorrectly and are potentially not checking for base-types when evaluating a drag and drop operation. I am currently researching this a bit more to see if this is the indeed the case, and I am attaching a modified sample project to demonstrate this change working.
Please let me know if you have any other questions or concerns on this matter.
0652.GroupEditorPrototype.zip
Right, so changing the child collection type in the Schema from ObservableCollection<Group> to ObservableCollection<GroupingItem> is a problem because then the tree allows Devices and SchemaNodes to be placed in that within Schemas, something that I'm trying to disallow. Only Groups should be allowed within a Schema's children, which was why that structure is set up that way.
Is this a bug within the tree then? It seems that what I want to do with this data structure should be possible, but it just won't allow the placement of a group within a group's children.
After a bit more investigation into this behavior, I do believe this is a bug in the XamDataTree control. It appears that we are caching a specific type for each “level” of nodes that corresponds to the underlying collection type. We are using that specific collection type when determining whether or not you can drag to other nodes, and so we are evaluating whether or not the Type Group is the same as the Type GroupingItem here, and if not, you will not be able to drag.
This is unexpected behavior, and as such I have asked our engineering teams to examine it further. To ensure it will receive attention, I have logged it in our internal tracking systems with a development ID of 273599. I will be linking this to a private support case so that you can be notified when a fix or other resolution is found. This support case has an ID of C-00220300 and you can access it after signing into your Infragistics account on the website here: https://account.infragistics.com/support-cases.
Great thanks for the follow up. Would it be possible to get an idea for how quickly a fix for this would be released?
Also, could you give us a stable workaround? What I've got for a workaround doesn't work very well.