A drag image remnant remains when dragging between different application instances

[willibrandon]

.NET version

.NET 7

Did it work in .NET Framework?

No

Did it work in any of the earlier releases of .NET Core or .NET 5+?

This feature is new as of .NET 7.

Issue description

When dragging between different application instances, and when a drag image is specified, a remnant of the drag image is incorrectly left displayed due to what I believe is a possible oversight in the DropSource implementation. Note that this issue does not occur when dragging within the same application instance.

A video demonstrating the drag image remnant when dragging between different application instances.

DragImage_between_different_app_instances.mp4

A video demonstrating the drag image behavior when dragging within the same application instance.

DragImage_within_same_app_instance.mp4

Steps to reproduce

WinformsControlTest project -> DragDrop

See the video demonstrating the issue when dragging between different application instances.

[willibrandon]

I have a possible fix!

[dreddy-work]

Thank you @willibrandon, We look forward to your PR.

[willibrandon]

Great. I’m afk right now but I’ll be back on Monday and will make it a priority.

[elachlan]

@willibrandon did your fix work and is it possible to submit a PR?

[willibrandon]

@elachlan - I had to take a break from this issue, but will take another look at it now.

[willibrandon]

@weltkante - Sorry to bother you, but I'm curious if you have any thoughts on this one, or any ideas on how I could've messed up the implementation? Things go wrong when dragging between different applications, and a drag image remnant remains.

[willibrandon]

@elachlan - I'll see if I can first reproduce the issue in a test, and if so, I'll open a draft PR to better facilitate this discussion.

[weltkante]

There are various things that look wrong

• contrary to what the docs require, the WinForms IDataObject doesn't support arbitrary private data formats and I see NotImplementedExceptions being thrown because things are failing to be stored. They don't seem to be related to the displayed artefact but its still worrying that the required contract is not correctly implemented and may lead to other failure cases.

Note The drag-and-drop helper object calls IDataObject::SetData to load private formats—used for cross-process support—into the data object. It later retrieves these formats by calling IDataObject::GetData. To support the drag-and-drop helper object, the data object's SetData and GetData implementations must be able to accept and return arbitrary private formats.

• the DropSource in GiveFeedback calls a DropTarget API on the "last seen HWND" (which ultimately is causing the artifact, it dissapears when you comment it out). Calling a DropTarget API from the DropSource seems suspicious to me and it might not be a supported scenario (but I didn't study the docs about this one so it might be ok). If its not a supported scenario you may be able to get it working by applying more tricks but it may break again in other edge cases.
• the HWND used by GiveFeedback to call DropTarget methods is only updated in DragEnterTarget but not in DragLeaveTarget, but fixing this doesn't fix the artefact because when you don't have a DropTarget you can't call the DropTarget-API

So in summary, you are probably misusing the DragDropHelper API and while doing so, incorrectly tracking the DropTarget.

I don't know why it works better in-process but my guess is that in the cross-process scenario you have two DragDropHelper instances (one in each process) while in-process you just have one shared by everyone, so that might mitigate the incorrect tracking of the DropTarget

I don't really have a good suggestion how to fix the problem, since its not part of the API design, when you move off a DropTarget you may actually not immediately move into a new DropTarget (and in fact you don't when you do the final Drop). After fixing the tracking you might want to do one final call against the old DropTarget inside DragLeaveTarget. This might cause flicker when immediately moving inside a new target which you could mitigate by a delayed call only done when DragLeaveTarget was not followed by a DragEnterTarget.

[willibrandon]

You are the man! I can't say that I have all of the issues you've identified here fixed yet, but I am close.

Please bear with me as I try to communicate this as precisely as I can.

It seems that in the cross-process scenario I'm not properly detecting that we're in a drag loop and because of that, I fail to set one of the arbitrary private drag and drop data formats, such as IsShowingLayer or IsShowingText, into the data object, thus resulting in the NotImplementedException. This issue, I believe, is straight-forward to fix. However, as you've also identified, this issue doesn't appear to be related to the issue with the displayed artefact in the cross-process scenario.

For the issue with the displayed artefact in the cross-process scenario, the only other thing I have to add to your observation is that I see a possible issue with the GiveFeedbackEventArgs equality implementation in that I'm not sure if the Effect property should also be included in the comparison. Omitting it appears to fix one of the issues with the displayed artefact in the cross-process scenario.