Click here to Skip to main content
15,943,294 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
The drag/drop associated events in WPF (DragEnter, DragOver, Drop, etc.) are fully fired and handled beautifully for "FileDrop" data originating from Windows explorer, as well as browsers (at least Firefox). However, they seem to be completely inert to "FileDrop" data drags originating from certain other applications.
(A number of solutions I've found point to issues with unequal UIPI levels, but these solutions seem to be unrelated as none of the applications have administrator privileges, nor does mine, nor does VS.)
Moreover those same drag/drop operations from the same applications fire perfectly if the target app is a WinForm app instead of WPF, so this is clearly a WPF issue. I can't redo my application as a WinForms app (nor do I wish to).

What I have tried:

Searching the net far and wide points to using ole32.dll
public static extern int RegisterDragDrop(IntPtr hwnd, IDropTarget pDropTarget);


which I have done my best to implement.
That is, I've created a class implementing IDropTarget:
internal class DropClass : IDropTarget ...

with the appropriate events (DragEnter, etc.)

Then I register my WPF window through RegisterDragDrop, immediately after InitializeComponent(), and I use that created class as the target.
I believe I've done it correctly, and yet none of the events of that class are being fired.
Incidentally certain comments suggested that when calling RegisterDragDrop the original WPF window setting "AllowDrop" should be set to false, so that has been tried as well.

My fallback hack solution right now is to use a transparent WindowsFormsHost over the WPF window to capture the OLE drag drop events, since only a WinForm seems to grab them. Much much less than ideal, of course. But I can't believe it's not possible to conduct filedrop operations from any application into WPF
Posted
Updated 31-May-22 20:13pm
v2
Comments
Dave Kreskowiak 31-May-22 10:31am    
Keep in mind that drag and drop has to be supported by BOTH your application AND the one you're dragging from. If the app your trying to drag from doesn't support drag and drop or doesn't support the formats your app is registered as expecting, it's not going to work.
mycenean 31-May-22 11:35am    
Good point, but in this case both apps definitely support dragging, as evidenced by the fact that the events from the (external) drag source are fired if the target is WinForms. With WinForms I can confirm that the content being sent by the drag source is a FileDrop. It's just that nothing is being fired at all if the target app is WPF.
mycenean 1-Jun-22 2:14am    
As a slight clarification to the above: My transparent WinForm hack solution is actually not WindowsFormsHost (WindowsFormsHost accepts the external drop events but cannot be made transparent). Instead I'm achieving WinForm transparency by inheriting Form in .NET Core and SetStyle(ControlStyles.SupportsTransparentBackColor).
[no name] 2-Jun-22 12:07pm    
Since it works for some and not others, I would see why the other don't work instead of trying to fudge my app to somehow capture it. See if you can copy to the clipboard and then see what the clipboard "says" it got.

https://docs.microsoft.com/en-us/dotnet/api/system.windows.clipboard?view=windowsdesktop-6.0
mycenean 2-Jun-22 14:08pm    
I'm very sure that the drag source app is just placing a FileDrop name as the data, since that what is reported in e.Data.GetDataPresent *if* the drop (receiving) app is WinForms. If the app is WPF, there is absolutely no response, no events, and of course the Cursor is the typical "None" DragDropEffect. Right, I don't want to fudge my app, which is why I'm asking for ideas as to why WPF won't accept the drop.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900