Clipboard errors

[bob laughland]

From within our C# .NET 3.5 WPF application I have this code below.
Basically all it does is you pass it some text, and it is written to
the clipboard.

It works fine for me, but my tester gets this exception

'OpenClipboard Failed (Exception from HRESULT: 0x800401D0
(CLIPBRD_E_CANT_OPEN)'

After he told me about that exception I made the code try again 5
times, and catch the exception, but he now always get the message at
the bottom that says 'here seems to be a problem with the clipboard.
Please try again'

Am I doing something silly here? What are your thoughts?

public static void SetText(Window owner, string clipboardText)
{
int attempts = 0;

while (attempts < 5)
{
try
{
Clipboard.SetText(clipboardText);
return;
}
catch (COMException)
{
Thread.Sleep(10);
attempts++;
}
}

MessageBox.Show(owner, "There seems to be a problem with
the clipboard. Please try again", "Clipboard Error.",
MessageBoxButton.OK, MessageBoxImage.Error);
}

 

[bob laughland]

Hard to say without knowing more.  A concise-but-complete code example  
_and_ complete information about the configuration of any computers where 
the code fails.

But, my first thought, assuming this only causes a problem on one specific  
computer, is that there's something on that computer that's interfering  
with the clipboard.

If the problem is more general, then perhaps you've got some other problem  
in your code not visible in the small portion you've included here.  E.g.  
another thread that's somehow locked the clipboard (has opened it but not 
yet closed it), or perhaps you're trying to execute the code on a thread  
that's not in STA mode.

Pete

OK. Thanks. I have heard of STA mode, but how does that apply here?

No other threads within our application are accessing the clipboard, I
am sure of that.

More importantly this problem occurs on virtual PC, and I have seen
this link

http://khason.net/blog/clipboard-setdata-getdata-troubles-with-vpc-and-ts/

which suggests that virtual PC could be the problem. But I just need
to understand why virtual PC would be a problem because we need to
know that if we release this to clients that it wont occur. They wont
be running in virtual PC of course.

On the PC with the problem (Vista installed under virtual PC) other
clipboard operations are working fine, i.e. from notepad. But they
would be accessing the clipboard not using .NET. Links on the net
suggest that it is just the .NET wrapper that suffers from this
problem.

 

[OmegaSquared]

Hello, Bob,

Re: "...virtual PC could be the problem. But I just need to understand why..."

I sometimes use TightVNC viewer to provide remote support. I have found
that it causes very a similar problem with dotNet clipboard access. My
current solution is basically the same as yours -- i.e. to sleep (10 ms) and
then retry. Sometimes this seems to work. Sometimes 10 retries (the maximum
I'm using) are not adequate.

I also would like to be able to understand this (and also have a more
definitive work-around). Users of this application are unlikely to have VNC
on their systems. But I do worry about what other applications they might
have that will interfere.

Cheers,
Randy

 

[Mark Hurd]

Hello, Bob,

Re: "...virtual PC could be the problem. But I just need to understand
why..."

I sometimes use TightVNC viewer to provide remote support. I have
found
that it causes very a similar problem with dotNet clipboard access.
My
current solution is basically the same as yours -- i.e. to sleep (10
ms) and
then retry. Sometimes this seems to work. Sometimes 10 retries (the
maximum
I'm using) are not adequate.

I also would like to be able to understand this (and also have a more
definitive work-around). Users of this application are unlikely to
have VNC
on their systems. But I do worry about what other applications they
might
have that will interfere.

Cheers,
Randy

I have also had RealVNC (often) and RemoteDesktop (Terminal Services)
(rarely) cause this. It is normally faster to close the connection and
reconnect than to wait to hope it fixes itself.

Also .NET's .SetText does use Windows messages, and thus needs a message
loop happening somewhere. Sometimes it works without it but that is also
often because something else, such as COM, has already created a hidden
window for a message pump.