Nested drop targets
dpisanu opened this issue · 7 comments
Hello all,
I currently searching for a way to configure the drag and drop in a way that in the use case of nested drop targets
The inner child get the drop handler call before the parent handler. Also i need a possibility to mark the drop "As handled" so that the parent does not get it call at all or can determine if the event has been handled.
Thanks in advance
This is some pseudo XAML code.
<ParentControl AllowDrop="True"
dragDrop:DragDrop.IsDragSource="True"
dragDrop:DragDrop.IsDropTarget="True"
dragDrop:DragDrop.DropHandler="{Binding}"
dragDrop:DragDrop.DragAdornerTemplate="{x:Null}"
dragDrop:DragDrop.EffectNoneAdornerTemplate="{x:Null}">
<ChildControl AllowDrop="True"
dragDrop:DragDrop.IsDragSource="True"
dragDrop:DragDrop.IsDropTarget="True"
dragDrop:DragDrop.DropHandler="{Binding}"
dragDrop:DragDrop.DragAdornerTemplate="{x:Null}"
dragDrop:DragDrop.EffectNoneAdornerTemplate="{x:Null}">
</ChildControl>
</ParentControl>
@dpisanu this is already possible by implementing the IDropTarget.
Now you can use the NotHanded
property.
In the main demo is a short example for using this property .
Hope that helps.
Yes and no.
I know that by setting NotHandled and then cutting the Drop Function short I can force the Event going to the next Child. This is a Preview Mechanism being Tunneled down.
My Scenario is though.
I have a Control and a Child Control. Both can take a DropInfo.Data of the same type.
Both Use Cases are valid.
Now the Parent handles it first and there is no way to distinguish if the DropTarget was the Parent or the Child.
So a Bubbling sort of Mechanism would be ideal. Bubble up from the Child upwards to the Parent.
Looks like I can do a HitTest ... let me check this and update some code here for you.
/// <summary>
/// Implements <see cref="IDropTarget.Drop" />
/// </summary>
public void Drop(IDropInfo dropInfo)
{
// Dirty hack because GONG Drag and Drop does not correctly support nested dropping targets for the same data
var childControl = dropInfo.VisualTarget as ChildControl;
if ( childControl != null)
{
var hitTest = childControl.InputHitTest(dropInfo.DropPosition);
if ( !hitTest.Equals(childControl) && !hitTest.Equals(childControl.Property) )
{
dropInfo.NotHandled = true;
return;
}
}
}
Was this ever implemented? Using 1.1.0, events are definitely tunnelling, and I'm not really a fan of InputHitTest workaround (which probably wouldn't even work with the Control structure I'm implementing).
I'm in a similar situation. I've tried using both DropEventTypes
and defining matching DragDropContext
s for one drag/drop pair and it makes no difference.
I have two separate ItemsControl
drag sources with different data types, and two corresponding drop targets, except one ItemsControl
drop target is within the DataTemplate
of the other ItemsControl
. The DropHandler
is a different class for each, so I only want DragOver
to set NotHandled = true
for the relevant target, so that Drop
will only be executed on the right class.
┌────────┐ ┌──────────┐
│Source 1│ │ Target 1 │
└────────┘ │┌────────┐│
┌────────┐ ││Target 2││
│Source 2│ │└────────┘│
└────────┘ └──────────┘
What I'm seeing is that I get the No
mouse cursor when dragging the inner data to the inner target if either handler leaves NotHandled == false
. If I set NotHandled = true
in both for the child data type, then it says I can drop, but for the entire child DataTemplate
, not just for the inner ItemsControl
. The drop only works if it's over the inner ItemsControl
(so the right outcome, but wrong user feedback).
Is there a way to get this to work properly with the current implementation without resorting to hit testing?