How to back up your Windows clipboard safely and correctly?

I am trying to back up the Windows clipboard. Basically, I use EnumClipboardFormats() to get all the formats currently on the clipboard, and then for each format I call GetClipboardData(format) .

Part of the data backup obviously involves duplication. I do this by calling GlobalLock() (which " GlobalLock() 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 select the data size by calling GlobalSize() , and then finally I will do memcpy() to duplicate the data, then I will of course call GlobalUnlock() when done.

Well, it works ... most of the time. My program is reset when GlobalLock() if the clipboard contains data with the format CF_BITMAP or CF_METAFILEPICT . After reading this blog post on Old New Thing ( http://blogs.msdn.com/b/oldnewthing/archive/2007/10/26/5681471.aspx ) I found out why the crash occurs: apparently, not all data is in the buffer exchanges are distributed using GlobalAlloc() (for example, CF_BITMAP data), and therefore calling GlobalLock() on this data fails.

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 up by the system. So, what I did was hard code in my program of all clipboard formats ( CF _ * ) that were not freed by the GlobalFree() system, and I just do not back up these formats; I missed them.

This workaround seems to work well. Even if the 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 did not experience any glitches. In addition, even if there is a bitmap in the clipboard and I skip some formats during the backup (for example CF_BITMAP ), I can still Ctrl + V paste the originally copied bitmap from the clipboard after restoring my clipboard backup, since the bitmap is also represented by other formats in the clipboard that do not cause my program to crash ( CF_DIB ).

However, this is a workaround at best. My fear is that at one of these times some strange format (possibly private, that is, one between CF_PRIVATEFIRST and CF_PRIVATELAST , or maybe some other type) will be on the clipboard and my program after calling GlobalLock() will work again. But since there does not seem to be much documentation explaining the best way to backup the clipboard, and it is clear that GlobalLock() does not work properly for all data types (unfortunately), I'm not sure how to deal with these situations. Is it possible to assume that all other formats, besides the formats listed in the previous URL that are not freed by GlobalFree() , can be "caught" using GlobalLock() ?

Any ideas?

+7
windows clipboard
source share
1 answer

This is nonsense since you cannot 100% backup / restore the clipboard. Many applications have used delayed rendering, and the data is not actually on the clipboard. When you ask to insert, they receive a notification and display the data. It will take several minutes and hundreds of MB for large amounts of data from applications such as Excel. Look at the number of formats listed on the clipboard when copying 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 this? How big is this raster map? Tip. Save all open documents before trying to do this, as you may have to reboot.

+1
source share

All Articles