Why is my delay-rendered format being rendered too soon?


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.)

Comments (5)
  1. mvadu says:

    "There will be a remedial course in the use of the FileGroupDescriptor sometime next year."

    Too much of future planing!!.. why don’t you provide the date also..

  2. Dean Harding says:

    why don’t you provide the date also

    Because Raymond reserves the right to insert new topics in the middle of the topic queue as he sees fit — thus making anything more precise than "sometime next year" impossible to predict.

  3. Ian says:

    For the impatient, the relevant MSDN article to get you started with FileGroupDescriptor seems to be:

    http://msdn2.microsoft.com/en-us/library/aa969394.aspx

    See the section headed CFSTR_FILEDESCRIPTOR.

  4. I agree: there’s no reason to use delayed rendering if it’s a format that is cheap to produce in the first place (in terms of time and memory).  Save Delayed Rendering for expensive formats with a low probability of use, such as Bitmap from a spreadsheet.

    OTOH, there is WAY too much clipboard monitoring going on.  Programs spy on the clipboard, performing a full-blown paste (even if it’s not apparent to the user) just to light up their "paste" buttons and menus.  Excessive, and invasive clipboard monitoring by programs that aren’t expected to be clipboard monitors, leads to lots of trouble for everyone.

    Visit my site for more on common clipboard mistakes and abuses…

  5. 640k says:

    (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.)

    I dont know what FileGroupDescriptor is, but I can imagine what it is, and I’m looking forward to additional "under cover" info.

    Your post was very useful anyway, thanks.

Comments are closed.