>>>I will do many more tests during the weekend, and report back. I really need to find the root of the problem.
>
>Hi Tore,
>
>I'm agreeing with other posters who diagnose a race condition- maybe involving parallel thread handling of the clipboard.
>
>Maybe you could avoid the issue altogether by concatenating a standard VFP string, then transfer that to _cliptext on completion.

Unfortunately I can't use a variable in my case.

However, I have done a lot of tests, and have found where the bottleneck is. In these tests I could use a variable, and I found out that when I wrote to the clipboard, I had to wait a short time before I could safely read it back. My tests showed that with a 50 mS delay, I didn't get any dropouts. With a 40 mS or shorter delay, the number of dropouts increased, and without any delay I got a lot of dropouts,

Here's the code I used:

DECLARE Sleep ;
  IN WIN32API ;
  INTEGER nMillisecs
Clear
For lnX = 1 to 80
  lc=''
  For lnY = 1 to 40
    lc = lc + Transform(lnY) + '-'
  EndFor
  _cliptext = lc + Chr(13)
  Sleep(50)
  ?_cliptext
EndFor

You can try different values for the Sleep() call, or commenting the whole line out.

What I find interesting is that with a short delay or none, I sometimes get several dropouts in a row. So my guess is that there's some windows service that occasionally blocks the access to the clipboard for a very short period.