Hi Tore,

on the old laptop I have with me at the moment I can verify erroneous behaviour.
As it probably is a race condition, it might happen on assign, access or both,
so I modified your sources a bit

#define WW_COMMENT * wait window '' timeout 0.01
#define CRLF  Chr(13)+Chr(10)
FOR ln = 1 TO 10
	= Tore_1(ln)
next
= Tore_2()

FUNCTION Tore_1(tnX)
_cliptext=''
For lny = 1 to 10
  WW_COMMENT 
  _cliptext = _cliptext + Transform(m.lny) + CRLF
Endfor
Wait Window "After" + transform(m.tnX) + CRLF + ;
_cliptext + STR(ALINES(laLine, _cliptext))

FUNCTION Tore_2
clear
_cliptext = ''
For lnX = 1 to 10
  For lny = 1 to 10
     WW_COMMENT 
    _cliptext = _cliptext + Transform(lnY) + '-'
  EndFor
  WW_COMMENT 
  _cliptext = _cliptext + "after " + Transform(m.lnX) + CRLF
ENDFOR
? "result"
? _cliptext
? OCCURS('-', _cliptext)
_cliptext = ''

I am mostly with Dragan, as _cliptext functionality exceeds normal variables.
So what is a "system variable" ? Something to read or write to the OS.
Help says about _cliptext:"Specifies the character expression to store in the Clipboard"

Uncertain if implementing read/write functions would have sidestepped current errors,
but _cliptext felt like a shortcut with no real reason to me.

As my clunker was not error free with the 0.001 timeout, but with 0.005,
(@Al: several doevents not working well enough here)
it might be a good idea to build a small checker program around this
to accompany your tool when run on OS / HW combinations you could not test on
plus ability to set the timeout via config file (which might be generated by the checker).

As I am thankful for your warning and I want to keep my hair, I'll bow out now.
But if you ever decide to target weightloss instead of hairloss as debugging result,
I'll be happy to donate a bit more...

regards
thomas

>>>Hi folks,
>>>
>>>For several weeks now I have been working on a Thor utility which will be available soon. This tool uses many Foxtools functions which are exposed in an object typically called loEditorwin, check https://github.com/VFPX/PEMEditor/blob/master/Documentation/pemeditor_editorwindow_object.md for details.
>>>
>>>My work has been delayed for a long time since the program failed occasionally, and seemingly with no pattern for when and how it failed. The errors were incomplete, inconsistent and the debugger didn't provide any help either.
>>>
>>>The program copies data programmatically back and forth between the editor and the clipboard, and manipulates it in between. But sometimes some of the data "disappeared" for no reason I could explain, and it made me lose my mind, and much of my hair...! :-)
>>>
>>>I was ready to give up, but as a last resort I tried to add a short delay. Lo and behold, that fixed it! And now I want to share it with all of you.
>>>
>>>To reproduce the error, try the following code:
>>>
>>>

>>>_cliptext=''
>>>For lnX = 1 to 10
>>>*  Wait Window '' timeout 0.001
>>>  _cliptext = _cliptext + Transform(lnX) + Chr(13)+Chr(10)
>>>Endfor
>>>Wait Window _cliptext
>>>

>>>
>>>Run it several times, and you will notice that sometimes the list of numbers isn't complete, and sometimes it is.
>>>
>>>Now remove the comment (*) and run it again. Now you will get the correct result every time!
>>>
>>>Conclusion: VFP needs some time to "settle" when you move data to and from the clipboard. A very small delay won't be noticeable, but it will fix the problem!
>>
>>Interesting. FWIW, on my development machine, I ran it 6 or 8 times and it worked perfectly each time without the delay.
>>
>>Tamar
>
>This is a longer test:

>clear
>_cliptext = ''
>For lnX = 1 to 10
>  For lny = 1 to 10
>     Wait Window '' timeout 0.001
>    _cliptext = _cliptext + Transform(lnY) + '-'
>  EndFor
>  wait window '' timeout 0.001
>  _cliptext = _cliptext + Chr(13)+Chr(10)
>Endfor
>?_cliptext

>
>The result was that there still are occasional dropouts, so I will do more test during the weekend.
>
>When I commented out the two Wait WIndow lines, the number of dropouts was sometimes high, sometimes low and a few times none...!