BUG: Retaining Clipboard IDataObject Causes Unexpected Result

An application holding on to a clipboard IDataObject pointer, and making repeated calls to IDataObject::EnumFormatEtc() through that pointer, may find that the set of formats returned by EnumFormatEtc() changes between calls.

As noted in the Object Linking and Embedding SDK version 2.01 documentation, an application that calls OleGetClipboard() to retrieve an IDataObject interface pointer should hold on to that IDataObject pointer only for a very short time.

Microsoft has confirmed this to be a problem in the products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

Steps to Reproduce

1. Copy an object from an OLE 1.0 server to the clipboard.
2. Call OleGetClipboard() to obtain an IDataObject pointer to the clipboard object.
3. Call IDataObject::EnumFormatEtc() to enumerate the available formats.
4. Without calling IDataObject::Release(), copy an object from an OLE 2.0 server to the clipboard.
5. Call IDataObject::EnumFormatEtc() again. The formats enumerated have changed to the formats provided by the new OLE 2.0 object.

The OLE2UI library's implementation of the Paste Special dialog box (provided in the Object Linking and Embedding SDK version 2.01) works around this problem. The Paste Special dialog box is launched by calling OleUIPasteSpecial(). If the user changes the contents of the clipboard while this dialog is up, the OLE2UI code detects the change and responds by ending the dialog box. When this happens, OleUIPasteSpecial() returns OLEUI_PSERR_CLIPBOARDCHANGED.

The dialog box detects changes to the clipboard contents by calling SetClipboardViewer() to splice itself into the clipboard viewer chain.