19

I am using the following code to copy text to the clipboard:

  Clipboard.Open;
  try
    Clipboard.AsText := GenerateClipboardText;
  finally
    Clipboard.Close;
  end;

Seemingly at random I get "Cannot open clipboard: Access Denied" errors. I'm guessing that these errors are caused by other application locking the clipboard, but I never seem to be doing anything with other applications that should cause the locks.

Strangely my users seem to be reporting more of the errors with Vista and Windows 7 than with XP.

Is there a way to check if the clipboard is locked before trying to access it?

norgepaul
  • 6,013
  • 4
  • 43
  • 76
  • 1
    Please note this snippet from Delphi's documentation: " Clipboard.Open -> Opens the clipboard, preventing other applications from changing its contents until the clipboard is Closed. Call Open before adding a series of items to the clipboard. This prevents other applications from overwriting the clipboard until it is closed. (When adding a single item to the clipboard, there is no need to call Open.)" – Gabriel Dec 16 '13 at 16:41

6 Answers6

25

This is not a Delphi problem. Because the clipboard can be locked any moment, even if you check, if the clipboard is currently not locked, it might become locked directly after the check.

You have two possibilities here:

  1. Don't use the Delphi clipboard class. Instead use raw API functions, where you have a little more fine-grained control over possible error situations.
  2. Expect your code to fail by adding an exception handler. Then add some retry code, i.e. retry to set the text three times, perhaps with exponential backoff, before throwing your own error.

I'd recommend the second solution, because it'd be the more Delphi-like approach and in the end will result in cleaner code.

var
  Success : boolean;
  RetryCount : integer;
begin
  RetryCount := 0;
  Success := false;
  while not Success do
    try
      //
      // Set the clipboard here
      //
      Success := True;
    except
      on E: EClipboardException do
      begin
        Inc(RetryCount);
        if RetryCount < 3 then
          Sleep(RetryCount * 100)
        else
          raise Exception.Create('Cannot set clipboard after three attempts');
      end else
        raise;  // if not a clipboard problem then re-raise 
    end;
end;
Daniel Rikowski
  • 71,375
  • 57
  • 251
  • 329
9

Strangely my users seem to be reporting more of the errors with Vista and Windows 7 than with XP

This may have to do with how Vista/Win7 deal with clipboard viewer notification. While they still support the XP "clipboard viewer chain", which sends one notification message that must be re-sent to each listener in turn (and if one app fails to do this, the other apps aren't notified). Starting with Vista, apps are notified directly. And there's nothing to keep them from trying to access the clipboard all at once.

Analogy: I have 3 children. I have a cake. With XP rules, I tell the oldest child to have some cake, then tell the next oldest child to have a slice. She gets her slice, tells her brother, he gets his, and tells his brother, who gets his, and everything proceeds in an orderly fashion.
Problem: The middle child takes the cake to his room, doesn't tell the youngest, and the youngest misses out.

With Vista/Windows7, that system still exists. But newer apps can request to be notified immediately, by me, as soon as the cake arrives in the kitchen. I shout "cake is ready!" and they all show up at the same time and try to grab some. But there's only one serving knife, so they have to keep reaching for the knife, failing to get it, and waiting for the next opportunity.

Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
2

Try to check GetClipboardOwner, if it's not null and not your Application.Handle, you cannot Open to modify it's content.
And even it seems good to go, it might not be anymore when you actually do it.
So add a try except in a loop until you get it or give up nicely (notifying the user for instance).

Francesca
  • 21,452
  • 4
  • 49
  • 90
1

There is no way to check for something and then depending on the result do something else with the expectation that it could not fail, because unless the check and the action are one atomic operation there is always the possibility that another process or thread does the same in parallel.

This holds whether you try to open the clipboard, open a file, create or delete a directory - you should simply try to do it, maybe several times in a loop, and gracefully handle errors.

mghie
  • 32,028
  • 6
  • 87
  • 129
1

First of all please notice that this probably isn't a problem in your application. Other applications locked the clipboard or messed up the notification chain and now your application fails to access it. When I do have problems like this I restart the computer and they magically go away... well... at least until I run again the application that creates the problem.

This code (not checked in Delphi) may help you. It won't fix the problem is the notification chain is broken (nothing except a PC restart will ever fix it) but it will fix the problem if an application is locking the clipboard for a while. Increase the MaxRetries if that pesky application keeps the clipboard locked for A REALLY LONG time (seconds):

procedure Str2Clipboard(CONST Str: string; iDelayMs: integer);
CONST
   MaxRetries= 5;
VAR RetryCount: Integer;
begin
 RetryCount:= 0;
 for RetryCount:= 1 to MaxRetries DO
  TRY
    inc(RetryCount);
    Clipboard.AsText:= Str;
    Break;
  EXCEPT
    on Exception DO
      if RetryCount = MaxRetries
      then RAISE Exception.Create('Cannot set clipboard')
      else Sleep(iDelayMs)
  END;
end;

Also, it may be a good idea to drop the 'raise' and convert it to a function and use it like this:

if not Str2Clipboard 
then Log.AddMsg('Dear user, other applications are blocking the clipboard. We have tried. We really did. But it didn''t work. Try again in a few seconds.');
Andreas Rejbrand
  • 105,602
  • 8
  • 282
  • 384
Gabriel
  • 20,797
  • 27
  • 159
  • 293
  • Your sleep isn't long enough. 15ms isn't going to do anything. After 5x15ms, whatever had the clipboard open probably still has it. – Chris Thornton Jan 10 '11 at 18:08
  • You may be right but on the other hand if you use a long delay you may have the application hang for few seconds just because the Clipboard is in use. Probably each programmer should decide how much "freeze" is acceptable. – Gabriel Jan 12 '11 at 15:58
  • Even better: The delay can be even used as parameter for the procedure. --- I just updated the code. – Gabriel Jan 12 '11 at 16:00
  • IMO, you're better with an escalating length of delay. These thins are unpredictable by nature. You don't know what app has the clipboard open, or why. And you don't know how many other apps are in the clipboard notiication chain. You may need to wait for several seconds before you can successfully have exclusive access to the clipboard. If 250ms isn't enough, next time try 500, then 1000 then 2000. So multiplying the (iDelayMs * RetryCount), gives you what you want. – Chris Thornton Jan 12 '11 at 16:21
-2

I guess you are running your app on Win 8 or higher.

Just right-click on your App .exe file, go to Compatibility tab and change compatibility mode on Windows XP or lower versions. It'll work, guaranteed!

Farshad H.
  • 303
  • 4
  • 16