OpenClipboard() fails

A friend of mine is using version 4.40. I am aware a lot of changes were made to clipboards since, but since my own digging in the source (and googling) reveals it might be a deeper issue, I'm posting none the less.

Basically, only one out of five OpenClipboard() attempts works or so. All others give the 'Cannot open the clipboard' error that is thrown at a few places (doc.cpp and methods.cpp). I'm personally lost, since it seems to be a MFC library call and google is full with messages about OpenClipboard() failing in applications as well.

He had the following stuff opened, in case it is something to do with other Applications: firefox, thunderbird, visual web developer 2008 express, dreamweaver CS4, YIM, SQL Management Studio Basic, Notepad, OO.o Calc

My own notice is that none of those are MS Office applications, which are apparently known for hogging the clipboard.

This error is especially annoying since it seems MUSHclient is copying at every character selected, meaning he can barely select a URL. Assuming you can't track down the error either - can MUSHclient be adjusted to only copy to the clipboard when the selection is completed (mousebuttonup msg)?

Just turn off the "copy selection to clipboard" option. I don't think that is very useful these days, now that the Ctrl+C problem is fixed.

That ignores the fact that some people actually prefer that behaviour over manually needing to hit the Ctrl+C combination. :)

I think that programmatically (ie. without user intervention) copying data to the clipboard hundreds of times, as you move the mouse over text, may possibly exceed the design limits for clipboard management. I note that a possible reason for the OpenClipboard failing is that the clipboard may be in use, or already open.

Perhaps one of the other programs he is running has some sort of auto-clipboard conversion running, and when it detects the clipboard has changed (somehow) opens it, converts it to an internal format, and then closes it. The time taken to do this would be finite, but normally well within the rate at which a normal human could be copying to the clipboard. However a programmatic high-speed series of copies may exceed its capabilities.

Your friend could try using the auto clipboard function with no other program running (eg. after rebooting) and then gradually adding the others back in, testing each time. That might show the culprit (if there is an obvious culprit).

Then it might be a case of not running (say) Dreamweaver at the same time as MUSHclient, or doing what I suggested, and manually copying to the clipboard.