search

microsoft / winfile

Original Windows File Manager (winfile) with enhancements
MIT License
6.86k stars 710 forks source link

Drag and Drop support #191

Open AFaustini opened 6 years ago

AFaustini commented 6 years ago

There is a way to implement drag and drop support from winfile to any other program?

craigwi commented 6 years ago

Winfile already supports some of the drag/drop and clipboard formats/operations. The original support was extremely limited and I improved that a few years back.

What specific cases don't work for you?

AFaustini commented 6 years ago

When i try to drag and drop from other program to winfile, works flawlessly. But when i try to drag and drop from winfile to elsewhere, doesn't work at all, with the mouse cursor changing to unavailable.

craigwi commented 6 years ago

There are some cases from WinFile to other programs that work, but there is no OLE drop source yet (https://docs.microsoft.com/en-us/cpp/mfc/drag-and-drop-implementing-a-drop-source). The headers have the corresponding definitions, but I never got that far.

AFaustini commented 6 years ago

This OLE drop source support aren't on the plans, right?

craigwi commented 6 years ago

Independent of who does the work, supporting the OLE drop source mechanism makes sense to me. The work is non-trivial.

Celandine commented 6 years ago

At the very least it would be nice to be able to drop from Winfile onto the desktop.

malxau commented 6 years ago

This is...annoying.

Before OLE drag and drop existed, there was a simple drag and drop mechanism used by the File Manager. It's still documented on MSDN and the OLE documentation refers to it: "OLE drag and drop is different from the File Manager drag-and-drop mechanism, which can only handle filenames and is designed specifically to pass filenames to applications." That's supposed to be a criticism, but the advantage is that the interface designed for passing around files is really simple to use when the requirement is to pass around files.

What really changed is Explorer is no longer calling DragAcceptFiles to accept files from this simple interface. It works fine in older versions of Windows - I just used @MartinPayne's port on NT4 to check my sanity, and sure enough, it works fine on NT4 and the same binary can't drag to Explorer on modern Windows. You can use WinFile on modern versions to drag files to other applications that support its interface, such as my media player. Explorer will even generate the old interface, so objects from Explorer can be dragged to Serenity, but WinFile doesn't register for its own WM_DROPFILES interface, so Explorer won't talk to it in that direction either.

The pragmatist in me realizes that there's no chance of Explorer supporting the old interface again, but it's really annoying that this used to work, and changes in Explorer prevent it from receiving files from WinFile. I'm also fairly confident that at one point WinFile supported WM_DROPFILES, but the NT 3.1 version doesn't seem to do it, so that's going back a long way.

schinagl commented 2 years ago

Independent of who does the work, supporting the OLE drop source mechanism makes sense to me. The work is non-trivial.

Well I think I did the C implementation of IDataobject IDropsource and related classes, but I'm currently struggling that other Droptargets accept my Dropsource. Maybe I didn't put the proper types into the dataobject. Have to play a bit.

roytam1 commented 1 year ago

WinFile doesn't register for its own WM_DROPFILES interface, so Explorer won't talk to it in that direction either.

but it is funny that you can start up 32bit winfile, then start up a 16bit winfile, and then DnD between them. winfile instances happily accept their own DnD mechanism(i.e. WM_QUERYDROPOBJECT and friends).