>Hi!
>
>In our Large VFP APP in the afterRowColChange() method we refresh childforms from one Form.
>bud sometimes VFP Stops directly after the last line in AfterRowChange()
>With the help of set coverage ... we see, no more Code runs. Bud VFP ends Work with "Not responding" and you can wait forever.
>
>If we insert
>wait window "" timeout 0.01 in the afterRowColChange()

I've discovered, the hard way, that newer windowses (i.e. the vista and later) poll apps, on a timer, for active status. If it doesn't reply, it gets a "(not responding)" attached to the caption, and any click on its window paints it milky whitish, so it looks dead. VFP app will reply when it's in a wait state - as done by your wait window, or otherwise by having an active form with at least one control enabled.

I had to do a lot of long batches, and echoed the log entries on _screen, and then it would just stop doing that because of the above condition, so I wouldn't know whether it crashed or is it still working but the windows doesn't consider it active and has blocked _screen updates. My solution was to call this:

	
#DEFINE hWindowsTapInterval	4.56	&& number of seconds Windows leaves me be
PROCEDURE tapdance(tn1, tn2)
*[2015/01/26 02:33:38] trying to avoid Windows blanking me screen
		IF SECONDS()> THIS.lastTap
			DOEVENTS FORCE
			WAIT WINDOW TEXTMERGE(" <<tn1>>/<<tn2>>") NOWAIT
			oLog.LOG(TEXTMERGE([<<tn1>> records done]))
			THIS.lastTap=SECONDS()+hWindowsTapInterval
		ENDIF
	ENDPROC

The value of interval is my best experimental approximation. The DOEVENTS FORCE did the trick. I was calling it often enough - every 100 records processed or thereabouts; it would actually doevents every 300 or 2000 records, depending on the speed of the process, and it wouldn't be labeled as "not responding". There were some minor glitches with this, but it generally worked fine.