views:

411

answers:

3

I have been developing an app in VB.NET which requires a control object (for example, a ListViewItem) to be dragged out of the form, and to a user-specified location (for example, on the desktop, or in a folder).

However, The file that is intended to be 'copied', as the 'ListViewItem' represents, does not yet exist. It needs to be downloaded and then placed in the user specified location. Am I able to get the path/location of the destination drop? I would then proceed to download the file, and then place it where the use specified.

I have looked at other questions regarding a similar issue, which details the dragging operation outside the form, its just there doesn't appear to be a way to determine where that short cut went or how to flag the destination location.

Essentially, I am thinking that it may require some sort of 'dynamic link' or 'virtual file' as I've seen mentioned elsewhere. Then, after the drop operation, somehow accessing this 'link' from my application, proceed to download the file and place it in the final drop destination.

Any help is appreciated, thanks in advance!


OUTCOME:

Roger Lipscombe provided a link that contained links to other articles, with what looks to be promising information. The following links may prove useful in implementing a drag drop operation without providing the exact data that is required in managed code.

+2  A: 

I'm sorry, but there is no way to get the target path of a DnD operation. Because the drop target may not even have a path!

See here for a more detailed explanation.

Of course, you could try to hook into the DnD, then ask for the target window and from there try to find the target path if the window is known to you (e.g., the window belongs to the explorer process).

Stefan
So in essence, it is a requirement to have the drag data specified? Can't we somehow make the data a place holder file, or some form of pointer that we can trace and locate at a later point?
Shadow
+2  A: 

You can ask Explorer to delay an IDataObject::GetData call to CFSTR_FILEDESCRIPTOR to when the drop actually occurs by responding CFSTR_PREFERREDDROPEFFECT in your IDataObject::GetData implementation. See http://hg.mozilla.org/mozilla-central/file/b49a6a8a4973/widget/src/windows/nsDataObj.cpp for an example. Note if the target is a virtual folder, the drop target is not obligated to honor your preference.

Explorer check clipboard formats for file name in the folling order

  1. CF_HDROP

  2. CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS

  3. CFSTR_FILENAME

Do not use CF_HDROP because it requires that the source file(s) actually exist somewhere in the file system. Use CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS instead.

Sheng Jiang 蒋晟
Cool, so how would I go about using that in managed VB.NET code? I don't write C so I wouldn't know how to go about making a wrapper for it.
Shadow
sorry, don't know VB.Net. Maybe you can use Reflecter to check how Windows Forms implements IDataObject.
Sheng Jiang 蒋晟
A: 

Do you really want to know where the "file" was dropped? Or do you just not want to provide the data up front?

If the latter, Raymond Chen has a whole series on implementing virtual drag and drop, in native code. David Anson translates it into managed code and adds asynchronous support.

Roger Lipscombe
Knowing where the file was dropped was the only workaround I could think of without using unmanaged code for drag drop operations.None-the-less, that link you provided; led to the managed code implementation of virtual file dragging. I haven't yet implemented, but the code article looks definitely like what I was looking for.Thanks :)
Shadow
Just add those relevant links into your answer (http://blogs.msdn.com/delay/archive/2009/10/26/creating-something-from-nothing-developer-friendly-virtual-file-implementation-for-net.aspx and http://blogs.msdn.com/delay/archive/2009/11/04/creating-something-from-nothing-asynchronously-developer-friendly-virtual-file-implementation-for-net-improved.aspx) and I will happily accept this answer as correct :)
Shadow
Updated with direct links.
Roger Lipscombe