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 exist. 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 file? 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 a FileGroupDescriptor. There will be a remedial course in the use of the FileGroupDescriptor sometime next year.)