Why can programs empty the clipboard when they start up?


Via the Suggestion Box, Johan Almén asks, "What was the rationale behind the decision to let Excel empty the clipboard when launched?"

Why can an application empty the clipboard? Because it's there.

After all, the point of the clipboard is to hold information temporarily. Programs are permitted to empty the clipboard, add data to the clipboard, or retrieve data from the clipboard. That's why it's there.

(I'm assuming that the naming of the program Excel was just an example of a program, and that the question wasn't "Why doesn't Windows have a specific check for the program EXCEL.EXE and block its clipboard access while still allowing clipboard access to everybody else.")

Okay, maybe the question wasn't so much "Why are programs allowed to empty the clipboard" as it was "Why are programs allowed to empty the clipboard when they launch?" Well, because that might have been the whole point of the program! Somebody might write a program called empty­clip whose sole purpose in life is to empty the clipboard. You run the program, it empties the clipboard, and then it exits. Short and sweet. If Windows didn't allow programs to empty the clipboard when they started up, then this program would not be able to get its work done.

You might not consider that particularly useful, but there are actually quite a few programs which empty the clipboard when they start up. For example, the clip program that comes with Windows takes its standard input and places it on the clipboard. Implied in that functional description is that it erases what used to be on the clipboard. Everything the program does is in its startup.

echo I'm on the clipboard! And I erased what use to be there.| clip

Many scripting languages provide access to the clipboard, if not natively, then through an extension. Since these are typically not GUI programs, as far as the window manager can tell, these programs as perpetually stuck in their startup code: They never go input idle because they never pump messages. Prohibiting programs from accessing the clipboard during startup means that console programs are effectively banned from modifying the clipboard at all.

Okay, maybe the question wasn't "Why are programs allowed to empty the clipboard when they launch?" so much as it was "Why are programs allowed to empty the clipboard outside of an explicit user action (like a click or a hotkey)?" Well, we still have the problem of programs whose design is to empty the clipboard without any user interaction, like all those console scripts. But you also remove many GUI usage patterns, such as pushing work to a background thread so that the program can remain responsive. And it would also prevent you from writing a program that modified the clipboard in response to a drop operation. I can imagine a program called file­contents­to­clip which just sits there and waits for you to drag/drop a file onto its window. When you do that, it opens the file and places the file's contents onto the clipboard. Since the drag/drop operation is handled by the drag source, the drop target receives no input and (according to the rule of "no clipboard access without user input") is denied permission to erase the old clipboard contents.

In order for these sorts of interaction models to work, there would have to be some sort of Allow­Clipboard­Access function (akin to Allow­Set­Foreground­Window) so that one process can temporarily transfer clipboard access permission to another process. It could be done, but it would make writing applications more complicated, because you would have to anticipate what operations might result in another application wanting to access the clipboard and scattering calls to Allow­Clipboard­Access in various places in your program. If you miss a spot, you'll get some bug filed against your program that says, "When I click the Preview button, and I've set my custom previewer to program X and configure program X to say 'always copy image to clipboard when previewing', the feature doesn't work."

The clipboard was part of Windows 1.0, and back in those days, you didn't have a lot of memory available. You had to get a lot done with very little. Programmers were trusted to use their great power with great responsibility. And besides, as we saw with programs like clip (and hypothetical programs like empty­clip and file­contents­to­clip), allowing programs to empty the clipboard at startup made it possible to write some interesting and useful tools. Windows historically didn't stop programmers from doing stupid things because that would also prevent them from doing clever things.

Comments (43)
  1. John says:

    "Programmers were trusted to use their great power with great responsibility."

    And everyone lived happily ever after.

  2. Mike Caron says:

    I think this was a mis-aimed question. A better phrasing would be:

    "Why the heck does Excel empty the clipboard when it starts up?"

    At which point, your reply would be:

    "I have no idea. Why don’t you ask the Excel team?"

  3. Marquess says:

    Huh? What’s next? People complaining that their (admin-made) login script cleans the Temp directory?

    “But I had important data in there! Why didn’t you back it up?”

  4. Tor says:

    Agree with Mike Caron. I think ‘let’ was not supposed to mean ‘allow’ but ‘make so that it’. "What was the rationale behind the decision to make Excel so that it empties the clipboard when launched?"

  5. GWO says:

    The question surely should’ve been "How did Excel’s non-standard, unecessary, unhelpful and annoying behaviour ever get past QA?"

  6. Aaron says:

    Maybe Excel’s behavior is a subconscious hint to users to keep the program open rather than opening and closing it repeatedly if they are going to be using it frequently.

    I can imagine a case where a non-geek office employee and regular user of Excel opens and closes spreadsheets 100 times a day.  To do this, initially they open and close the Excel application 100 times a day.

    However, when they notice that opening excel causes the annoying behavior of clearing their clipboard, they decide just to leave excel open all day and simply close the individual documents when they are done with them, thereby improving overall system efficiency.  

    …Or maybe that’s a stretch.

  7. kog999 says:

    yes i think he meant to ask. "why does stupid excel empty my clipboard of important copied things when it starts up, what a dumb way to design excel". possibly written with a few explimation points and more capital letters. i just tried copying something to the clipboard and then opened excel and my clipboard was not lost. i was able to paste it just fine. was this behaviour changed at some point, i’m running windows 7 and excel 2007.

  8. Neil (SM) says:

    I interpreted also as asking why Excel does what it does (or used to do, actually).  As if the wording "decision to let Excel" actually meant something like:

    "What was the rationale behind management’s decision to let the Excel people develop a program that clears the clipboard…"

    On a related note, hey Raymond, why doesn’t iTunes provide a better way to merge two libraries between computers without creating duplicates?

  9. Marquess says:

    “On a related note, hey Raymond, why doesn’t iTunes provide a better way to merge two libraries between computers without creating duplicates?”

    Oh, that one’s easy: It is an Apple product. It doesn’t matter if it does what it’s supposed to do (or if it does it right), as long as it looks really stylish.

  10. 254 says:

    "Programmers were trusted to use their great power with great responsibility."

    But don’t tell anybody. The clipboard is (thankfully) one of those Windows components that the majority of programs manage to implement the right way (basically). Once marketing folks get to know the power there is, we’ll see programs with options such as "Automatically copy the address of the support web site to the clipboard each time a message box appears" or "Always replace contents of clipboard with trusted format".

  11. mh says:

    Interesting one.  Mark me down as a person who would have thought that the clipboard is something that belongs to the user, not the program, and therefore the program should only interact with it (on any level) as a result of explicit user actions and intentions.  Otherwise it’s "hands off".

    Then again, that’s not the only weird clipboard-related thing Excel does – even typing in a cell will cause it to empty the clipboard (confirmed with 2007).

  12. acq says:

    254, you’re right! Imagine whatever you copy, what you paste is "I’m sorry, Dave. I’m afraid I can’t do that." As the matter of fact one internet browser (with some animal in the logo) did something very similar to me and made me switch to another, less popular one. More years went by and as I search the web it appears it’s still unsolved! Never attribute to malice…

  13. Don Munsil says:

    I just tried this. I copied some text, launched Excel 2007, and then pasted the text into Excel. Worked fine. I then tried typing in a cell, as @mh suggested, and the clipboard was still retained. Maybe mh has some kind of odd Excel add-on installed that has the side effect of clearing the clipboard when you type in cells. That would be some pretty annoying behavior, and would not, in fact, make it through Excel’s QA process.

    So I guess the answer to the implied question of why Excel clears the clipboard at launch is: it doesn’t. Maybe some older version did, though I really have a hard time imagining it. I’d be more inclined to blame an add-on, macro, or virus.

    However, Raymond’s answer to the actual question asked is both true and useful.

  14. Dan says:

    @254 There are already some websites that will monitor when the user copies text and will send a copy of the text to an ad site…

    http://yro.slashdot.org/story/10/01/14/1818222/Tynt-Insight-Is-Watching-You-Cut-and-Paste

  15. Alexandre Grigoriev says:

    ………………….

    [wall of text, because of his termonuclear social skills Raymond just didn’t understand the user’s concern]

    …………………

  16. What makes me wonder is why Windows still uses a linked list to inform programs about clipboard modifications. Every clipboard viewer has to save the next window handle. If done that wrong, some windows dont get informed or may even crash due to stack overflow when some program inserts a loop in the viewer chain.

  17. AD says:

    Hmm… Someone above tested Excel 2007, I just tested Excel 97. Mine didn’t clear the clipboard either, so if the clipboard clearing feature ever existed in Excel it was probably only for a small number of versions.

    Since it was not a standard feature for Excel, it becomes a lot easier to understand why Raymond would opt to interpret the question in the way he did. If he hadn’t, it would have been meaningless.

  18. Cyrill says:

    I think that mh and Johan Almén have some evil script/macro installed…

  19. GregM says:

    mh is actually correct here, but only if Excel put the stuff on the clipboard in the first place.  As soon as you do anything that causes the selected cells to no longer be selected, the cells that excel put on the clipboard are removed from it if they are still there.  This essentially results in the clipboard being cleared.  If you put something else on the clipboard first, Excel (2007 at least) doesn’t remove that.

  20. anonymous says:

    Why are programs like Word allowed to empty the clipboard when exiting?

  21. Stephen Jones says:

    Excel 2003 doesn’t do this. It will take stuff copied from Excel off the clipboard when you start it or type in another cell in Excel, though starting Excel leaves stuff saved from other programs on the clipboard.

    The Office clipboard keeps the stuff.

  22. Stephen Jones says:

    —-"Why are programs like Word allowed to empty the clipboard when exiting?"—-

    They don’t normally.

  23. 640k says:

    VB6 IDE clears clipboard on exit. Bye bye only-copied source code, you should have saved!

  24. Rick C says:

    "What makes me wonder is why Windows still uses a linked list to inform programs about clipboard modifications. "

    Because while it’s not perfect, it works, and replacing the existing system would break all the currently-working apps.

  25. "Windows historically didn’t stop programmers from doing stupid things because that would also prevent them from doing clever things."

    That pretty much sums up everything that is great and terrible about Windows.

  26. Don Reba says:

    Neither Excel 2000, 2003, nor 2010 actually empties the clipboard on startup, so Raymond’s interpretation of the question must have been correct.

    Also, thanks for the ‘clip’ program tip.

  27. Anonymous Coward says:

    I’d have to agree with most of the posters above that Raymond misinterpreted the question. I’ve experienced that behaviour as well as a myriad other clipboard related annoyances with a clean install of Excel (it was the one in Office XP or the one just before that – I can’t remember and I don’t use Excel any longer). My guess is that the concept behind Excel’s clip functionality is flawed and that the implementation is really really buggy. So that’s probably the only answer Johan is going to get I’m afraid, even though it’s anticlimactic and disappointing.

  28. Gabe says:

    Maybe the original poster meant "closed" instead of "launched". The answer to that would be that the clipboard isn’t necessarily some global object. When you run "clip" it copies the text to a globally accessible block of memory. But when you copy an Excel worksheet to the clipboard, Excel just tells Windows "I have the clipboard; let me know when you want the contents of it". So when you close Excel, the clipboard data goes with it.

  29. Lisa says:

    @anonymous Some programs don’t convert the data to the "regular" clipboard until you need it. (They may use an "internal" clipboard for copy and paste within the document, esp. when the data is large.) Case in point: Corel Draw will ask you when you "exit" if you want to keep what’s on the clipboard available to other applications. If you say "yes", Corel’s process will actually hang around hidden until you’ve finished with the stuff on the clipboard. If you say "no" the process closes immediately. Many other apps work the same way, but they aren’t always so clear about what they are really doing.

  30. Don Munsil says:

    Aha, I understand what at least some people are talking about. Excel has an idiosyncratic way of handling the Cut and Copy operations for ranges of cells. This is probably a relic of making them work like Lotus 123 or something.

    When you select a range of cells in Excel and select Copy, the cell range changes state and is now in a "ready to copy" state. Then you select a location for the cells and select Paste, and the cells copy over. If after the copy and before the paste you start typing into another cell, Excel goes out of "copy mode" and the range of cells in copy state goes out of that state and the copy selection is "lost."

    Also, selecting a range of cells and choosing "Cut" from the menu, or Ctrl-X, doesn’t actually remove the cells from the spreadsheet. The cells go into a "ready to cut" state until you select a destination and select "Paste."

    I can see how people would perceive this as Excel "clearing the clipboard" but it’s just that cutting and copying cell ranges doesn’t work like other programs. As to why I don’t know, but some kind of legacy behavior is my guess. And at this point it’s not something that can be changed without messing up millions of people who understand the quirks of Excel.

    I still have no idea where this idea that Excel cleared the clipboard on startup came from. Maybe there was a version of it once that did that.

  31. 254 says:

    [Why are programs like Word allowed to empty the clipboard when exiting?]

    This is probably due to delay rendering. Word presumably produces data in several clipboard formats only on demand (WM_RENDERFORMAT). When it terminates it would need to generate all those formats, in case they are needed afterwards. This can be time and memory consuming, so Word asks if it can skip this step.

    (In my opinion, delay rendering is a bad idea anyway: Instead of making the copy operation slow, it makes the paste operation in another program slow, blocking both programs and making the other program look bad. There seems to be no way to abort the GetClipboardData call. If a program cannot produce a particular format fast, it should not offer it on the clipboard at all.)

  32. Not nice says:

    The clipboard wasn’t even suited for 16-bit windows requirements. Bloated AND missing features. Badly designed API, both badly coded AND badly designed. It should have been a stack or fifo from day 1, and more resource friendly, not a impossible task.

  33. Random832 says:

    "(In my opinion, delay rendering is a bad idea anyway: Instead of making the copy operation slow, it makes the paste operation in another program slow, blocking both programs and making the other program look bad."

    Nevermind the fact that it makes the paste operation – and the whole process of copying and pasting – a whole lot less slow than the copy operation would have been without it. But I guess making sure the delay is in the right place for ignorant users to assign blame is much more important than actually minimizing the delay.

    Excel 2007 places 29 formats on the clipboard, [word places 17]and some usage patterns of excel result in quite large amounts of data on the clipboard for short times. Saving it right away would take an unacceptable amount of time and global memory. This becomes even more apparent when you’ve got remote desktop clipboard forwarding, and it would have to copy all of the data across the network, instead of just the one format.

  34. 254 says:

    "Nevermind the fact that it makes the paste operation – and the whole process of copying and pasting – a whole lot less slow than the copy operation would have been without it."

    My point is that delayed rendering is only justified if the program knows in advance that it can produce the data really fast. And then there is less of a point in not producing the data right away (only memory is saved).

    If the copy operation is slow, it should never be delayed because the pasting program has no chance of realizing what is going on (GetClipboardData simply does not return). Then again, the copying program would have been able to give feedback (such as a progress bar) while generating the data.

  35. Gabe says:

    254: Imagine that you have a large Excel worksheet, say 100MB, and that you want to make a copy of it. You perform "Select All", "Copy", "New", and "Paste". This is a common operation, which in this case would only take a couple seconds and use 200MB of memory (100MB for the original plus 100MB for the copy).

    However, without delayed rendering, the 29 different formats would consume 2900MB of global memory until you clear the clipboard(!) — because Excel doesn’t know which format you’ll eventually use, or if you’ll even use it (which in this case you wouldn’t because the data never had to leave Excel’s process). Since your 32-bit computer obviously doesn’t have 2900MB of global address space sitting around, Excel would have to say "Sorry, you’re trying to copy too much data" or "Sorry, some clipboard formats won’t be available".

    Why on earth would you want to waste so much time transferring all that data back and forth when it never has to leave Excel’s address space, never has to be translated into any other format, and only has to be on the clipboard for the few seconds it takes to do the copy?

    For another example, imagine that you’re using RDP to manage a server over a 1Mbps connection. You have several hundred GB of log files that you want to move from one folder to another, so you go into Explorer, select the files you want to move, Cut, go to the folder you want them to be in, and Paste. Since the files never have to leave the filesystem, you can easily move 500GB of files instantly.

    In your hypothetical world either you wouldn’t be able to perform the operation, or you would have to wait a couple months while the 500GB of files needlessly gets transferred to your local system (to make paste operations faster, of course!) at 1Mbps.

    Quite frankly, I would not want to be in a world without delayed clipboard rendering.

  36. Anon says:

    I bet the paperclip did it.

  37. peterchen says:

    I’ve always treated the clipboard as "touch only if the user asks explicitely for it".

    That should make you happy, because it prevented more than one case of "we don’t need expensive automation, we are good with recording keyboard macros and using the clipboard" – automation.

    Excel’s clipboard handling is weird: any action after the copy kills the clipboard. I understand the implementation, and can deduce the reasons for it, but it is/was a pain. If I had an interesting article for every time I’ve copied, prepared the paste target, only to find my copy is "gone", I’d be a successful blogger by now.

  38. Neil (SM) says:

    Alexandre, Anonymous Coward, and others.

    Raymond absolutely did not misinterpret the question, he simply answered exactly what was asked. Remember that this blog has a range of topics, but they are specifically directed: it is about Win32 programming, Windows UI development, Windows shell programming, development history, and shell/windows UI decisions in general.  

    In fact, at the top of the suggestion box thread Raymond specifically mentioned topics he likes to cover (mainly what I mentioned above), and a few topics he would not cover — one of them specifically is "Microsoft software that isn’t Windows. (Exchange, Office, …)"  

    So in that context, I believe Raymond gave the correct answer question and interpreted it correctly. Raymond is going to respond to the questions only with answers  relevant to this blog. The person who asked the question should not have expected Raymond to answer a question about an Excel design decision — especially when Raymond made clear in advance what he was going to talk about.

  39. Joe says:

    Programs should obviously have access to the clipboard, but they should not override any content the user has put their without the user’s permission. It’s a matter of usability, not security.

    For instance, the PowerBuilder IDE uses the clipboard to communicate autocomplete text from the dropdown to the script window. By doing so, it erases whatever was there before. this is a horrible misuse of the clipboard, and extremely annoying from the user’s point of view. It’s legal, but it stinks.

    There are a lot of ways program can harm the user by doing things they are allowed to. It doesn’t mean they should do them, though.

  40. LL(1) says:

    In Office 2000 the only way to put an icon on a command bar button was to use the <a href="http://msdn.microsoft.com/en-us/library/aa215654(office.10).aspx">PasteFace</a> method. This did improve already in Office XP with the introduction of the Picture and Mask properties. With the Ribbon UI of Office 2007 and 2010 things got even better and the ribbon did ease add-on development quite a bit.

    Of course, it is not unexpected to see an add-on still use PasteFace for "backward-compability" reasons.

    Thus the answer to mr. Almén’s question would be: Upgrade the add-on.

  41. David Anderson says:

    A better question is why Excel empties the clipboard after pasting. Did it never occur to the Excel people that anybody would want to paste the same information twice?

    I know that backward compability is a big issue for Microsoft, but I refuse to see why there isn’t at least a "Make Excel use the clipboard the same way as all other applications on the planet" option.

  42. kog99 says:

    Obviously Raymond knew the real question “why was excel designed this way” and I love how Raymond took this clearly off topic suggestion entry on a specifically banned topic (Microsoft products that are not windows) and wrote an entire article about the clipboard out of pure snarkyness. Answering every question except the one question the writer and actually inserted in. Thats the type of stuff that keeps me coming back for more

  43. mh says:

    "The clipboard wasn’t even suited for 16-bit windows requirements. Bloated AND missing features. Badly designed API, both badly coded AND badly designed. It should have been a stack or fifo from day 1, and more resource friendly, not a impossible task."

    The *clipboard* is bloated!  I know that some in the Linux arena can be occasionally prone to bouts of fantasy and exaggeration, but claiming that the *clipboard* is bloated is surely stretching credibility.

Comments are closed.