End preview and/or DrapDrop operation in DrapDrop handler

[BoehserWolf]

My use case:

• attach data to the DragDrop operation
• in the DragDrop handler directly use the data AND create a runtime created modal form which uses the data

Problem:
If a new form is created directly in the event handler the preview still persists.
Is there any chance to end the DragDrop operation in the DragDrop handler?

Below my simplified DragDrop handler which illustrates the problem. The form may be any empty form.

private void PictureBox_DragDrop(object sender, DragEventArgs e)
{
    PictureBox pb = sender as PictureBox;
    if (pb == null) return;

    // allow valid format/object
    var data = e.Data.GetData(e.Data.GetFormats()[0]);
    if (!typeof(DnDArgs).IsAssignableFrom(data.GetType()))
        return;

    DnDArgs args = data as DnDArgs;

    using (FrmTest frmTest = new FrmTest())
    {
        frmTest.ShowDialog(this);
    }

    pb.Image = args.MyImage;
}

[BoehserWolf]

One possible workaround for this problem is to wrap this into a delegate like so:

this.BeginInvoke((Action)(() =>
{
    using (FrmTest frmTest = new FrmTest())
    {
        frmTest.ShowDialog(this);
    }

    pb.Image = args.MyImage;
    lblDst.Text = $"{args.MyUser.FirstName} {args.MyUser.LastName}";
}));

This works but seems to be a bit odd to me.

I also played around with you library. It seems to me that there should be some way where the DragDrop operation can be cancelled from within the DragDrop handler. Therefore I tried to play around with _previewFormController?.Stop(), StopTrackingForDeferredStartOnMouseMove() and CleanUp() within your Method private void Target_DragDrop(object sender, DragEventArgs e) in class DragOperations. Unfortunately I did not find a quick "fix".
But maybe you have another idea?

[awaescher]

Oh my god, I am sorry I must have overseen this.

Yeah, that's an issue. The handler for the drop event fires before any code of mine can interact. That's why the overlay form is not hidden in that case. This happens for every form that is blocking the UI, like modal forms or Message Boxes.

I don't see a problem with your workaround as BeginInvoke() is doing exactly this: Queueing your action at the end of the current UI operation(s). That way, the code to hide the overlay is executed first.

However there is a nicer approach in my opinion, but it requires to know the receiver control(s) when you initialize the Drag&Drop operation:

You can skip the To() method to implement the event DragDrop on the receiver control itself (like you did) - or, if you know the receiver(s) already, you can define them there.
To() takes the receiver(s) and an lambda action how the receiver(s) should react when they receive the drop. FluentDragDrop makes sure this action is executed on the UI thread, so it's safe to access UI elements and even show dialogs or MessageBoxes.

pic.InitializeDragAndDrop()
  .Copy()
  .Immediately()
  .WithData(pic.Image)
  .WithPreview(Grayscale((Bitmap)pic.Image)).LikeWindowsExplorer()
  .To(PreviewBoxes, (target, data) =>
  {
    target.Image = data;
    MessageBox.Show("Done");
  });

Hope this helps.

[awaescher]

Just opened issue #17 that makes this use case clearer and doesn't need To() .