Copyright 1999-2007, Thornsoft Development, Inc.
There are some ways of using the clipboard that seem ok while you’re developing the application, but which later on, cause trouble, either within your application, or when interacting with other apps or clipboard viewers. Some are errors, others are just things that you need to be careful about, so that compatibility problems are minimized.
- Multiple Updates – One common clipboard error is where an application updates the clipboard several times in a row, for the same operation. If the user copies something, then you should create one, and only one, clipboard update. You’re supposed to open the clipboard, erase the clipboard, add your data (for all formats), close the clipboard. It’s simple – open, clear, update, close. However, sometimes people (or large companies) write programs that open, clear, close, open, update, close. See those two open..close operations? That’s two WM_DRAWCLIPBOARD messages that go out on the chain. Even worse is when they use separate open,update,close operations for EACH FORMAT. There was one version of a popular spreadsheet (with X and L in the name) that would send over 20 clipboard updates when copying a graph. They would add a format each time.
You can use the “Clipboard Viewer / Ignore Demo” test application to see if you’re causing multiple updates. Download, unzip, run the included .EXE file, and turn on the clipboard monitoring. Watch the log, and the “update counter”. If you see it increment by 1, when you copy from your app, then you are ok. If you see it jumping by more than one, then you are causing multiple updates – that’s bad. Get the demo app here: http://www.thornsoft.com/dist/techsupport/ignoredemo.zip
- Local Clipboarding – does your application cut ‘n’ paste locally, without using the clipboard? If so, then consider having a clipboard format available that will faithfully reproduce the data. And tell your users to enable this format in ClipMate, or other clipboard extender.
- Programmer Short-Cut – “Programs should not transfer data into our out of the clipboard without an explicit instruction from the user.” — Charles Petzold, Programming Windows 3.1, Microsoft Press, 1992
If you use the clipboard to move card faces, toolbar icons, or bits of text within a program, or between programs, without the user performing an explicit cut/copy or paste, then you are using the clipboard as a crutch. Remember – the clipboard is there for the convenience of the user, not the programmer. Do not do this! If you read chapter 16 “The Clipboard” of the book mentioned above, you’ll see that allowances are made for programs that are “specifically designed to manipulate the clipboard”, such as ClipMate.
Any time a program puts data onto the clipboard, without the user’s knowledge or consent, that’s an abuse. And it’s documented on the The n Habits of Highly Defective Windows Applications page. http://www.flounder.com/badprogram.htm#clipboard
- Improper or Incomplete implementation of Clipboard Viewer.
While any app can use Clipboard Viewing to monitor the clipboard, not all apps implement this properly. If you don’t properly handle all clipboard message types, you will sever the clipboard chain, and cut off other apps from receiving messages. You need to do much more than just handle updates – you need to pass them along to the next app in the chain, and you need to TRACK who the “next app” actually is. It can change! And when you’re done, you need to gracefully exit the chain. If any of this is news to you, please review the Clipboard Viewer page.
- Failure to CLEAR The Clipboard – If you don’t clear the clipboard before updating, any formats that you don’t explicitly overwrite, will be left over from before. This is bad. For example, let’s say that the user had copied this paragraph from his web browser. It’s on the clipboard in a variety of formats, such as CF_TEXT, Rich Text Format, CF_HTML, etc.. Now your app places some TEXT on the clipboard, without first erasing the clipboard. Works great if you paste into Notepad – you get the text from your app. But if the user pastes into Word, then he’ll get the Rich Text Format representation of the data from the web page. If he does a Paste Special | Unformatted Text, then he’ll get yours. He’ll be very confused, and angry. Be sure not to make this mistake.
- Non-Viable Clipboard Data – When data is copied to the clipboard, is it really ok to bring it back later? Sometimes there are private formats that have all of the information needed to faithfully reproduce the item copied, but it’s only good in the “here and now”. If you copy it today, make sure you can paste it tomorrow. That means no dependency on pointers to internal data structures, for example. There is nothing worse than pasting in an old clip from a clipboard viewer, and having your application GPF or go into a loop, because you didn’t think about having the data come back later on. You can test this easy with Windows. Just open the standard windows clipboard viewer. Copy something from your app. Save as TEST.CLP in the Windows clipboard viewer (clipbrd.exe or clipbook.exe). Reboot. Reload the clip in clipbrd.exe. Paste into your app. Did it work? Great. Did it crash? Ooops.
Solution? One approach would be that while pasting, check the clip before pasting the format in question. If it is invalid, don’t paste it. Warn the user to not bother capturing this format, as it isn’t useful later on.
- See Also: Common Clipboard Viewer Mistakes
- Microsoft Platform SDK – Base Services | Interprocess Communication | Clipboard | Clipboard References | Clipboard Messages
- Microsoft Platform SDK – Base Services | Interprocess Communication | Clipboard | Using The Clipboard | Creating A Clipboard Viewer Window
The above two topics, while available in the MSDN, are currently online at:
In case they’ve moved it, do a search on: “Clipboard Viewer Windows”