Nested drop targets

[Daniel P]

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>

[Jan Karger ツ ☀]

@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.

[Daniel P]

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.

[Daniel P]

Looks like I can do a HitTest ... let me check this and update some code here for you.

[Daniel P]

/// <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;
      }
   }
}

[Jan Karger ツ ☀]

@dpisanu This issue should now work with the latest pre-release 1.0.0-ALPHA015

[Nick Fisher]

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).

[las-nsc]

I'm in a similar situation. I've tried using both DropEventTypes and defining matching DragDropContexts 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?