Holy cow, I wrote a book!
Here's a customer question:
I've put data on the clipboard as delay-rendered,
but I'm getting a WM_RENDERFORMAT request
for my CF_HDROP for many operations even
though nobody actually looks at the files.
Operations such as right-clicking a blank space on the desktop
or opening the Edit menu.
I don't want to render the data until the user hits Paste
because generating the data requires me to download the
file from a Web server.
The CF_HDROP format is a list of file names,
and at the time the format is generated, the files must already
That's because the whole purpose of CF_HDROP
is to describe files that already exist.
These simple operations cause a request for CF_HDROP
because, as a simple list of file names, it is expected to be
a fast format.
The data object merely has to provide a list of things that already
exist; it doesn't have to go make them.
It's interesting that the customer wants to delay generating the
CF_HDROP format until the user selects Paste,
because the shell is asking for CF_HDROP specifically
to see whether it should enable the Paste command in the first place!
That you shouldn't generate
dynamic data in response to CF_HDROP
is also clear when you think about the lifetime issues.
If you're going to generate the files on the fly,
when do you know that it's safe to delete them?
If the user drops the file onto Internet Explorer or Firefox,
the Web browser is going to view the file as a Web page.
You get no notification when the user closes the Web browser,
and therefore you don't know when it's safe to delete the file.
The CF_HDROP format describes files that already
exist independent of the data object.
What is the correct thing to do if you want to delay-render a virtual
Use the FileGroupDescriptor clipboard format.
That's what it's for:
Delay-rendering of virtual file contents.
(I'm assuming an advanced audience that knows how to use
There will be a remedial course in the use of the FileGroupDescriptor
sometime next year.)