How ownership of the Windows clipboard is tracked in Win32
In Win32, there is the concept of a clipboard owner. How does that work?
The intended rule is that the clipboard owner is the window that created the data that is currently on the clipboard.
The intended usage pattern for putting data on the clipboard is
- Call
OpenÂClipboard(hwnd)passing the window that you want to become the new clipboard owner. (For the purpose of discussion, let’s say that the clipboard opener is the window handle that was passed to theOpenÂClipboardfunction.) - Call
EmptyÂClipboard()to wipe out the previous contents. - Call
SetÂClipboardÂData()once for each piece of data you want to put onto the clipboard. - Call
CloseÂClipboard()to indicate that you are done setting the clipboard data. - Congratulations, you are now the clipboard owner.
The clipboard owner receives a WM_ message when somebody requests data from the clipboard that had been set as delay-rendered. It also receives a WM_ message as part of the window destruction sequence if it is still the owner of the clipboard at the time it is destroyed. Delay-rendering lets you defer the creation of complicated clipboard data until the point it is requested. And if nobody ever requests it, then you saved yourself a lot of work.
Bonus reading: What is the proper handling of WM_ and WM_?
The clipboard owner also receives a WM_ message when the clipboard contents are subsequently emptied. This tells the clipboard owner that it can free any memory that it had been using to produce the delay-rendered data.
The intended usage pattern for reading data from the clipboard is
- Call
OpenÂClipboard(hwnd)passing the window that is reading the clipboard. - Call
GetÂClipboardÂData()to retrieve data from the clipboard. - Call
CloseÂClipboard()to indicate that you are done reading the clipboard data.
If everybody follows the rules, then it all works out.
Spoiler alert: Not everybody follows the rules.
Some programs open the clipboard with the intent of adding data to the clipboard, rather than replacing it with new data. Those programs call OpenÂClipboard, followed immediately by SetÂClipboardÂData without an intervening EmptyÂClipboard.
There was historically no enforcement that the caller of SetÂClipboardÂData is the clipboard owner. Back in the days of 16-bit Windows, the system assumed that applications were honest and played by the rules for the common good. (And for compatibility, these shenanigans need to continue to work, even though the world has become a more dangerous place.)
This “bonus clipboard data” scenario creates a bit of a problem, since there is only one clipboard owner (which you can interrogate by calling GetÂClipboardÂOwner()), but there are now two windows who collaborated to put data onto the clipboard. Who is the owner?
Ownership of the clipboard changes as follows:
- When
EmptyÂClipboard()is called, the current clipboard opener becomes the clipboard owner. - When the clipboard owner is destroyed, the clipboard owner resets to null.
Therefore, the clipboard owner can be summarized as “the window that most recently called EmptyÂClipboard, if it still exists.”
Bonus chatter: There is also special handling of the case where somebody passes NULL to OpenÂClipboard, indicating that “nobody” is opening the clipboard.
Light
Dark
8 comments
It would be more neat if there could be multiple clipboard owners and each of them associated with their clipboard data.
What’s the use of “clipboard owner” except in the “delayed rendering” scenario or to perform check on the “process integrity level”? Seems these all are related to the clipboard data themselves instead of the clipboard as a whole.
Under what valid conditions can data from multiple owners be on the clipboard simultaneously? It’s supposed to be cleared every time you copy something new, and you can only copy from one window at a time.
The bonus reading also explains why
SetClipboardDatadoes not change the ownership to thehwnd(“current opener”) passed into the last successful call toOpenClipboard— duringWM_RENDERFORMAT, the current opener is the window requesting data, and the owner should still be the window rendering the data, which callsSetClipboardData.On the topic of copy/pasting, does anyone know why the selection behaviour when double clicking a word in a Windows text box always includes the whitespace after the word, rather than just the word itself? This really bugs me!
I know there will be some obscure software that depends on this behaviour, but I wish there was a setting to exclude the whitespace.
I don’t have an answer to your question, but you can easily get rid of the space while selecting by double-clicking the word and moving the cursor to the right while still holding the button down. You can also select multiple words by doing the same thing, just moving to the last word (or special character) you want to select before releasing the button.
That’s genius, I had no idea you could hold the mouse button down after a double click! I’ll definitely be using that trick going forward, thanks Ed 🙂
No problem! I wish someone had told me about this too 🙂
You can similarly select entire paragraphs at a time by triple-clicking any part of the paragraph and dragging the cursor around.
If you’d like to know about another obscure text selection trick: To select larger portions of text, there’s a much easier way than holding down the left button and dragging the cursor around. You can simply left-click the portion of the text just before the first character you want to select, then hold Shift and click just after the last character. If you want to change your selection, you can keep holding Shift and clicking (or dragging) until you get it right.
By the way, quite a few of the tricks I know I learned completely by accident. It’s funny how many years, decades we let go by oblivious to these amazingly simple yet headache-saving tools. This reminded me to do something I’ve always thought about but keep forgetting: search for a compilation with more such tricks!
Withoutspacestherereallyarenowords.