Jeremy points out that the documentation for Set­Clipboard­Data says that the clipboard owner must not call Open­Clipboard when responding to the WM_RENDER­FORMAT and WM_RENDER­ALL­FORMATS messages. On the other hand, the documentation for WM_RENDER­ALL­FORMATS says that the owner must call Open­Clipboard and Empty­Clipboard. Which is it?

It’s none of them!

Let’s start with WM_RENDER­FORMAT. The reference implementation for a WM_RENDER­FORMAT handler goes like this, with all error handling deleted for expository purposes:

case WM_RENDERFORMAT:
 CLIPFORMAT cf = (CLIPFORMAT)wParam;
 hData = GenerateFormat(cf);
 SetClipboardData(cf, hData);
 return 0;

In response to WM_RENDER­FORMAT, you simply place the format on the clipboard. No opening is required. In fact, attempting to open will fail because the clipboard is already open: It has been opened by the application whose call to Get­Clipboard­Data triggered the delay-render!

Next comes WM_RENDER­ALL­FORMATS. The original reference implementation goes like this, again with error checking deleted:

// code in italics is wrong -- see discussion below
case WM_RENDERALLFORMATS:
 OpenClipboard(hwnd);
 SendMessage(hwnd, WM_RENDERFORMAT, CF_FORMAT1, 0);
 SendMessage(hwnd, WM_RENDERFORMAT, CF_FORMAT2, 0);
 CloseClipboard();
 return 0;

In response to WM_RENDER­ALL­FORMATS, you open the clipboard, then render all your formats into it, and then close the clipboard. And one way to render your formats is simply to send yourself a fake WM_RENDER­FORMAT message, which gets the code in the earlier code block to generate the format and place it on the clipboard.

So you see that everybody is wrong!

The WM_RENDER­ALL­FORMATS handler does call Open­Clipboard—if you tried it without the Open­Clipboard call, you’d notice that the data never made it to the clipboard—and it doesn’t call Empty­Clipboard. (If you did, you’d notice that the Empty­Clipboard would have wiped out your non-delay-rendered data!)

Where did I get these reference implementations from? I got them from the Windows 3.1 SDK. (And that explains the bug; read on.)

In real life, you probably would also listen for the WM_DESTROY­CLIPBOARD message so you would know that you are no longer the clipboard owner, in which case you wouldn’t bother rendering anything.

I haven’t written code in a while, so let’s write some code. Start with our scratch program and make these changes. We’ll start by writing it incorrectly:

BOOL
OnCreate(HWND hwnd, LPCREATESTRUCT lpcs)
{
 if (OpenClipboard(hwnd)) {              
  EmptyClipboard();                      
  SetClipboardData(CF_UNICODETEXT, NULL);
  CloseClipboard();                      
 }                                       
 return TRUE;
}

const WCHAR c_szText[] = L"hello";                            
                                                              
HANDLE                                                        
OnRenderFormat(HWND hwnd, UINT fmt)                           
{                                                             
 if (fmt == CF_UNICODETEXT)                                   
 {                                                            
  HGLOBAL hglob;                                              
  if (SUCCEEDED(CreateHGlobalFromBlob(                        
                            c_szText, sizeof(c_szText),       
                            GMEM_MOVEABLE, &hglob))) {        
   if (!SetClipboardData(fmt, hglob)) GlobalFree(hglob);      
  }                                                           
 }                                                            
 return 0;                                                    
}                                                             
                                                              
void                                                          
OnRenderAllFormats(HWND hwnd)                                 
{                                                             
 if (OpenClipboard(hwnd)) {                                   
  OnRenderFormat(hwnd, CF_UNICODETEXT);                       
  CloseClipboard();                                           
 }                                                            
}                                                             
                                                              
    HANDLE_MSG(hwnd, WM_RENDERFORMAT, OnRenderFormat);        
    HANDLE_MSG(hwnd, WM_RENDERALLFORMATS, OnRenderAllFormats);

This program puts delay-rendered text on the clipboard when it starts up, When the request for text arrives, we just return the word hello. If we are asked to render all our formats, we render all our formats by calling our internal function once for each format we support. (All one of them.)

There’s a tiny race condition in that implementation above, though. What if somebody takes ownership of the clipboard while you’re trying to render all your formats? Let’s force the race condition. Set a breakpoint on the On­Render­All­Formats function, run the program, and close the window. The breakpoint will hit.

Switch away from the debugger and open Notepad. Type 123 into Notepad, then select it and type Ctrl+C to copy it to the clipboard.

Notepad will hang for a while, since the window manager is trying to send a WM_DESTROY­CLIPBOARD message to tell the previous clipboard owner that it is no longer responsible for the data on the clipboard. Let the call time out, at which point Notepad will wake back up and put 123 text on the clipboard. Now resume execution of the scratch program, so that it puts the Unicode word hello onto the clipboard.

Okay, go back to Notepad and hit Ctrl+V. Look, it pasted hello instead of 123. Oops, our delay-rendering program destroyed the clipboard as it exited. If the application had put something more complicated on the clipboard, then our scratch program would have created a mishmash of old and new data.

To protect against this race condition, make the following small change:

void
OnRenderAllFormats(HWND hwnd)
{
 if (OpenClipboard(hwnd)) {
  if (GetClipboardOwner() == hwnd) {
    OnRenderFormat(hwnd, CF_UNICODETEXT);
  }                                 
  CloseClipboard();
 }
}

After opening the clipboard, we check if we are still the window responsible for the clipboard contents. Only if so do we render our delay-rendered formats.

Exercise: Why is the Get­Clipboard­Owner test done after the Open­Clipboard? Wouldn’t it be better to bail out quickly if we are not the clipboard owner and avoid opening the clipboard in the first place?

Answer to exercise: Moving the Get­Clipboard­Owner test ahead of the Open­Clipboard reintroduces the race condition we are trying to fix. The program might be the clipboard owner at the start of the function, but then it gets pre-empted after Get­Clipboard­Owner and before Open­Clipboard and takes a long time to page in; say, because it’s running over the network or some other slow medium. During that time, the same scenario occurs that we are trying to defend against.

But all is not lost. We can do a Get­Clipboard­Owner as an early-out, but do another one after the Open­Clipboard just to be sure.