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?

Excellent, this was kind of the direction that I was heading in. I think the one question that I have is whether you would recommend using the IsEnabled pattern to enable/disable each item, or if directly manipulating the IsDropTarget property will work just as well? In my limited testing it seems to work well, but I am unclear if there are downsides to directly manipulating the control like that.

Hello Tracie,

I believe that both the IsEnabled pattern and the IsDropTarget will work equally as well with respect to the ability to drag the node to another tree or another node. The reason that I had originally recommended usage of IsEnabled though, is because that will “grey out” the nodes that cannot be dragged to as well as preventing the actual drag and modifying the cursor when you drag over it. The IsDropTarget will only change the cursor.

In my personal opinion, the IsEnabled bit is a bit more user-friendly as it provides an extra layer of being able to see where you can drag to, but the actual functionality is essentially the same either way.

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

Andrew thanks so much, this has been very helpful. One more thing that may complete the picture.

When iterating through the nodes collection, is there a way to know what the parent node is at any given point? The IsEnabled path is not working for me because of the common base type that I have to use, so doing this in the viewmodel (while it would be ideal) doesn't appear to be an option. Can you advise a way to traverse back up the tree if needed?

Traversing down is not a problem given that every node has a nodescollection that makes the recursive piece down through the tree pretty easy.

Or....would it be possible to bind IsDropTarget on the NodeLayout to a property on the viewmodel? (I've tried this with no success.) That would be ideal, but I'm thinking you might have suggested it if it were possible.

Hello Tracie,

Thank you for your update on this matter.

In order to access the parent node from a child XamDataTreeNode, I would recommend using the node.Manager.ParentNode property path. If the current “node” has a ParentNode, this will return it, else it will return null.

Regarding binding the IsDropTarget to the NodeLayout, I do not believe this would be an option if you are using the common base type. The value of that IsDropTarget will blanket onto every node in that particular NodeLayout. Furthermore, the NodeLayout object is not actually a visual element in WPF, and so binding the properties there might be a bit complicated. You would likely need to do a RelativeSource Self binding to get the Tree from the NodeLayout and then use its DataContext in order to bind its properties.

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

I posted this earlier, but it didn't seem to take.

I've got this mostly working. I ended up not using either pattern of setting IsDropTarget or IsEnabled because it seemed to completely block the ability to reorder items within one of the child collections. I've come up with a type structure that leverages how the tree allows or disallows dragging based on types, and it works the way we need in almost all cases laid out in my first post. Here is how it is set up:

Schema, has one ObservableCollection<Group>
Group : GroupingItem, has one ObservableCollection<GroupingItem>
Device : GroupingItem
SchemaNode : GroupingItem

There are 2 issues:

1. The tree won't allow me to add a group to another group. I don't understand why since the group implements GroupingItem. Any ideas? I've hijacked the drop event to create a copy and force the drop to occur, but it creates a copy instead of a move. Even better, would it be possible to give the user a choice to move or copy through a keyboard modifier (or some other way)?
2. The cursor when dragging over the group is disabled. Any way to change it to the appropriate template when dragging a group into another group?

I have a sample of my project, but can't seem to attach it. I'll try in a separate post.

EDIT: Is there a way to upload a sample? It doesn't seem to let me.

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.

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.

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.