-
Notifications
You must be signed in to change notification settings - Fork 6
Frequently Asked Questions
When dragging a file from my application to the Explorer, how can I determine the folder where the file is dropped?
In short, you can’t.
You must understand that the drag/drop API works the same for all applications that uses it, and the Explorer is just like any other application. The drag/drop API provides a framework that facilitates the interaction between a drop source and the target, but since the drop target can do anything it wants with the data it receives, there is no way to communicate the destiny of the data back to the drop source in a uniform way.
One target may chose to display the dropped data (e.g. notepad), another one to upload it to a web server (e.g. a FTP client), a third to move and rename the file (e.g. the Recycle Bin) and a fourth may chose to copy or move the file (e.g. Explorer).
In my experience there is never any real need to know the destination of a drop to the Explorer. If you find that you do need this, you should rethink your solution.
What is the difference between the drop source components’ AllowAsyncTransfer property and the Execute methods’ Asynchronous parameter?
The Execute methods Asynchronous parameter specifies if the source should perform the transfer in a background thread.
The AllowAsyncTransfer property specifies if the drop target is allowed to perform an asynchronous transfer.
The two are completely independent. One does not have priority over the other.
Asynchronous transfer on the source side is an “invention” of mine. It can be done even if the drop target doesn’t support, and thus doesn’t take an active part in, asynchronous transfer.
Asynchronous transfer on the target side is a COM drag/drop feature (see IAsyncOperation in MSDN). It requires that both the source and the target support asynchronous transfer. All the Drag and Drop Component Suite components support asynchronous transfer but, apart from Windows Explorer, few applications has implemented the feature.
An optimized move is simply a move operation where the drop **target** moves the data from the source to the destination location.
In a conventional move operation, the source and the target must cooperate in order to complete the operation. First the target makes a copy of the data at the desired location. Then, when the target has completed copying the data, it hands control back to the source who then deletes the original data. This procedure can be very inefficient because it requires two simultaneous copies of the data.
With an optimized move, the target handles the entire move operation and signals the source that an optimized move took place upon completion.
The Drag and Drop Component Suite supports Optimized Move on both the source and target side.
Make sure that the source or target isn't running as administrator.
In modern versions of Windows (Vista and later) it isn't possible to drag between applications running with different privilege levels.
The only way around this limitation is to use the ChangeWindowMessageFilterEx API function together with old-style WM_DROPFILES drag and drop. See the WM_DROPFILES example.
ChangeWindowMessageFilterEx is implemented in the Drag and Drop Component Suite by the UnblockDropFilesMessages function.