>>>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.