Is there a maximum size for Windows clipboard data? Because I’m getting null for something I know should be there
A customer had a program that opened a very large spreadsheet in Excel. Very large, like over 300,000 rows. They then selected all of the rows in the very large spreadsheet, copied those rows to the clipboard, and then ran a program that tried to extract the data. The program used the GetÂClipboardÂData function to retrieve the data in Rich Text Format. What they found was that the call to GetÂClipboardÂData was returning NULL. Is there a maximum size for clipboard data?
No, there is no pre-set maximum size for clipboard data. You are limited only by available memory and address space.
However, that’s not the reason why the call to GetÂClipboardÂData is failing.
There are two ways to make clipboard data available. One is to put the data directly on the clipboard at the time you take ownership of it. Another option is to declare that you have data of a particular type, but instead of putting the data on the clipboard, you say, “If anybody asks, let me know, and I’ll produce the data.” This is known as clipboard delay-rendering, and it is a common optimization for data formats that are rarely used or expensive to produce. If somebody asks for the format, the clipboard owner gets a WM_ message to say, “Somebody wants that data, can you produce it now?”
Excel does not operate natively in Rich Text Format. The Rich Text Format data that it places on the clipboard is delay-rendered. And then when another program asks for the Rich Text Format data, Excel says, “Oh yeah, just hang on a second, let me go get that for you.” Mind you, Rich Text Format is not the best format for a data table. As its name suggests, Rich Text Format is designed for text. It can represent basic tables, but that’s not its bread and butter.
When the system asks a clipboard owner to render clipboard data, it sends the WM_ message and waits up to 30 seconds for it to return. If the clipboard owner fails to produce the data within 30 seconds, then system abandons the request, and GetÂClipboardÂData returns NULL.
What’s happening is that this table is so large that it’s taking Excel longer than 30 seconds to produce the Rich Text Format table. The GetÂClipboardÂData function times out and returns NULL.
Next time, we’ll see what we can do to extend this timeout.
Light
Dark
7 comments
Interesting, thank you.
Thanks for the write-up, very informative. I think my immediate thoughts are:
-why 30s?
-how one might provide extra resources to excel or similar application to increase the amount of data that can be converted and beat the current 30s limit. I suppose it depends on the application and the format of the data copied.
Edit (off topic): is the suggestions box now deprecated? i tried in vain to find an open one.
Users get bored, yeah? And Raymond did promise a follow-up…
(Off topic) Tried to authenticate using my Windows Live ID and got “error creating user ‘1’”. Facebook worked fine, lol.
Very interesting, thanks for that writeup! It makes sense that it works that way frankly.
But, since the client app is waiting for the producer the whole time, and I presume the client will wait effectively forever until a response is received (vis a vis, the timeout is at the system level, not the client app level), whether that response is null or actual data, how about the idea of a system-generate dialog at the end of the timeout period that says something like “This operation is taking longer than expected, do you want to continue to wait?” If yes, wait another 30 seconds, and so on, for as long as the user wants or it takes to get the data.
Given the proper wording in the dialog, I could see that being pretty user-friendly and would allow for arbitrarily large clipboard content to be delivered even if it took minutes, and this way you don’t have to try and come up with the “right” wait time (I might even suggest lowering that 30 seconds to 10 or 15 seconds, but that’s a separate consideration).
Hmmm… This gives me more theories now about why I sometimes have the snipping tool in Windows 11 freeze. I’ll make a small annotation, ctrl+c, alt-tab to Teams, and ctrl+v. Freeze for 30s of the snip tool. Not every time though, which has made reproducing for the feedback tool annoying.
Something to do with delay rendering, although I feel this freeze would affect the consumer of the clipboard rather than the producer, unless there’s something interesting going on with clipboard history in the middle
At this point it’s not entirely clear that the clipboard is even a reasonable way to transfer data from Excel to this custom application.
Working in the financial services industry, I got a chuckle out of a very large spreadsheet being only about 300,000 rows.
I’m not saying it’s a good idea, I’m not defending the practice- just pointing out that “very large” means very different things to different people, in ways I sometimes find amusing.