Clipboard errors
bob laughland
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);
}
Peter Duniho
<peter.m...@gmail.com> wrote:
> 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?
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
bob laughland
wrote:
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.
Peter Duniho
<peter.m...@gmail.com> wrote:
> OK. Thanks. I have heard of STA mode, but how does that apply here?
Because the thread calling that method has to be STA. And only the main
thread in a .NET GUI application is STA. For console applications, you
need to include the appropriate STAThreadAttribute attribute on your
Main() method. For threads other than the main thread in any program, you
need to call Thread.SetApartmentState() as the first thing in the thread.
If you know that your thread is for sure already in STA mode, then my
comment doesn't apply at all. If you don't, then first thing you might
want to do is verify that it is.
That said...
> 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.
That actually makes sense, at least in a brain-storming sort of way. That
is, while I haven't used Virtual PC, I've used other virtualization
software, and something they tend to have in common is the ability to
share the clipboard between host and guest. But, it's entirely possible
that one way Virtual PC is doing this is actually opening the clipboard
periodically to check to see what's there and then copying the results
back to the host OS if it's changed (and vice a versa).
This means that you may very well have a process on the OS that is
regularly opening (and thus blocking access to) the clipboard.
I don't have any specific information that would suggest this is actually
what's going on. But it does make sense to me, given what else you've
said so far.
Have you tried upping the number of retries, to see if you can just force
the thing through eventually? Alternatively, rather than hinging on
retries, perhaps keep retrying for a specific amount of time (say, 1
second) and use a call to Thread.Sleep(1) to make sure that between tries
you give every other process a chance to complete whatever it's doing (if
you're hogging the CPU while you check the clipboard, you could easily
just make the operation take longer than it otherwise would).
> 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.
To some extent, this is a Virtual PC bug if it happens only when you're
running on Virtual PC. Why it happens only with .NET applications and not
unmanaged code, I can't say. Perhaps Virtual PC has hooked something in
the OS with respect to the way unmanaged code does it, but not how .NET
does it. It might be interesting to write a simple unmanaged program that
accesses the clipboard the same way that .NET does, to see if you can
reproduce the problem without .NET. If you can, that's a lot stronger
evidence that Virtual PC simply has a bug.
Pete
Mark Hurd
news:3D989A16-6B07-46F1...@microsoft.com...
> 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.
--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)