如何安全正确地创建Windows剪贴板的备份？

Question

I'm trying to create a backup of the Windows clipboard. Basically what I'm doing is using EnumClipboardFormats() to get all of the formats that exist on the clipboard currently, and then for each format, I'm calling GetClipboardData(format) .

Part of backing up the data obviously involves duplicating it. I do that by calling GlobalLock() (which "Locks a global memory object and returns a pointer to the first byte of the object's memory block." ) on the data returned by GetClipboardData() , then I fetch the size of the data by calling GlobalSize() , and then finally I do a memcpy() to duplicate the data. I then of course call GlobalUnlock() when I'm done.

Well, this works... most of the time. My program crashes at the GlobalLock() if the clipboard contains data with the format or . After reading this Old New Thing blog post ( http://blogs.msdn.com/b/oldnewthing/archive/2007/10/26/5681471.aspx ) I found out why the crash occurs: apparently not all data on the clipboard is allocated using GlobalAlloc() (such as data), and so calling GlobalLock() on that data causes a crash.

I came across this MSDN article ( http://msdn.microsoft.com/en-us/library/ms649014#_win32_Memory_and_the_Clipboard ) and it gives a list of clipboard formats and how they are freed by the system. So what I did was hard-code into my program all of the clipboard formats ( ) that are not freed by the GlobalFree() function by the system, and I simply don't back up those formats; I skip them.

This workaround seems to work well, actually. Even if a bitmap is on the clipboard, or "special" data (such as rows copied from Excel to the clipboard), my clipboard backup function works well and I haven't experienced any crashes. Also, even if there's a bitmap on the clipboard and I skip some formats during the backup (like ), I can still Ctrl+V paste the originally-copied bitmap from the clipboard after restoring my clipboard backup, as the bitmap is represented by other formats on the clipboard as well that don't cause my program to crash ( ).

However, it's a workaround at best. My fear is that one of these times some weird format (perhaps a private one, ie one between and , or maybe some other type) will be on the clipboard and my program, after calling GlobalLock() , will crash again. But since there doesn't seem to be much documentation explaining the best way to back up the clipboard, and it's clear that GlobalLock() does not work properly for all datatypes (unfortunately), I'm not sure how to handle these situations. Is it safe to assume that all other formats -- besides the formats listed in the previous URL that aren't freed by GlobalFree() -- can be "grabbed" using GlobalLock() ?

Any ideas?

Answer 1

This is folly, as you cannot 100% backup/restore the clipboard. Lots of apps used delayed rendering, and the data is not actually on the clipboard. When you request to paste, they get notified and produce the data. This would take several minutes and hundreds of MB for large amounts of data from apps like Excel. Take a look at the number of formats listed on the clipboard when you copy from Excel. There will be more than two dozen, including Bitmap, Metafile, HTML. What do you think will happen if you select 255x25000 cells in Excel and copy that? How large would that bitmap be? Tip: save any open documents before attempting this, as you're likely going to have to reboot.