A customer was writing a program that performed virtual drag/drop. They were using the IStream technique but found that many applications don't support drag/drop of virtual content. They support only CF_HDROP. What's more, often these applications query for CF_HDROP on DragEnter not because they want to access the file, but just because they want to get the file names (for example, because they want to put up the no-entry cursor if the file types are not ones the application supports).

Given that we want to be able to drop content onto applications which do not support drag/drop of virtual content, we have the problem of knowing exactly when to generate the content into a temporary file. If we generate the content too soon, then we may end up going to a lot of effort of creating a file that won't actually be used; if we generate it too late, then the application will try to open the file and find that it isn't there. When is the correct moment to generate the content? Is there some set of rules by which applications which do not support virtual drag/drop indicate whether they are obtaining the CF_HDROP just to see the names of the files, and whether they are obtaining it because they want to go open the files?

If you think about it, you already know the answer to this question because you already do it yourself when you write code that operates the client side of the drag/drop contract. When you write your program that accepts CF_HDROP content, do you use any special signal to tell the data object, "Hey, I'm asking for CF_HDROP just because I want the file names, but I promise not to try to open the files yet"? No, you don't, so why would you expect any other application to? Even if there were rules surrounding this signaling protocol, the fact that they are widely ignored (because even you yourself ignore them) means that you can't rely on the client performing them anyway.

The rule for CF_HDROP is that at the moment you offer CF_HDROP content, the files must already exist. The CF_HDROP clipboard format was created by File Manager in Windows 3.1, and File Manager did not support virtual content. The only thing it knew how to drag and drop was files, and the only thing it could drag was files that already existed.

In a sense, the rules around CF_HDROP were not so much codified by rule as codified by circumstance. Since the only things you could drag were files that already existed, those became the de facto rules for CF_HDROP.

Sorry.

Note that there is a little you can do: If an application calls QueryGetData for CF_HDROP, that does not force you to create the file content yet, because QueryGetData is just a yes/no query as to whether you could produce CF_HDROP if asked. You're not being asked to do so, so you can just say "Why yes, I have files" even though you don't yet. It's only at the GetData that you have to return a list of file names and therefore must create the files.

Most applications are kind enough to use QueryGetData when they are not interested in the files yet but only in the potential for files, but there are some which use GetData on the DragEnter, and those applications will force you to commit to creating the content even if the user ultimately abandons the operation without dropping. (You could try deferring the creation until your IDropSource::QueryContinueDrag returns DRAGDROP_S_DROP, but programs which sniff the file contents during DragEnter will not find the file there, and they probably won't like that. It also doesn't work if the transfer is done via copy/paste rather than drag/drop—and you need copy/paste support for accessibility—since your drop source is not active during a copy/paste.)

Exercise: How do you know when it's safe to delete the temporary files?