Pitfall 1: OLE Initialization
Any function using OLE may not work or show unexpected behaviour when OLE is not initialized. So don't forget to call AfxOleInit() from InitInstance().
Pitfall 2: COleDataSource Allocation
When using SetClipboard(), COleDataSource objects must be allocated on the heap and not on the stack. Looking at the MFC sources, you will find a call to InternalRelease() at the end of the SetClipboard() function. InternalRelease() is implemented in the CCmdTarget base class and is finally using delete this to destroy the object. Therefore, the COleDataSource object must be allocated on the heap and the object is no longer valid upon return from SetClipboard().
Pitfall 3: Memory Leaks when using DoDragDrop()
Contrary to SetClipboard(), the COleDataSource object is not destroyed automatically. So this must be done in your own code using InternalRelease() or ExternalRelease() (recommended, calls InternalRelease() if not aggregated). Don't use delete.
Pitfall 4: Using Data Rendering With the Clipboard
When using data rendering, data are only copied to allocated memory or file when used. This is especially useful with large amounts of data and when providing multiple clipboard formats. But with clipboard operations, there are two drawbacks:
- Nothing is copied when the source application or window has been closed meanwhile.
- Copies those items that are selected when the insert operation occurs, not those that were selected when the
SetClipboard() command has been called.
Pitfall 5: Drag&Drop may Not Work When Applications are Executed by Different Users
This applies to Windows Vista and later with enabled UAC. When the target application is executed with higher privileges than the source application, Drag&Drop is not supported (the cursor does not change to indicate the possibility of moving or copying). In the other direction, the cursor indicates that Drag&Drop is possible, and when dropping the move or copy effect is returned by DoDragDrop(), but nothing is dropped. See also this link [^].
