Thx for in-depth-description!

Quick follow up: physical machine park here mostly using Intel CPU screen driver, only 1 machine with dedicated graphic card (not too current NVidia), which I mostly use for compiling - eye/screen is mostly on Laptop I usually take with me. Other "typical" screen HW are AMD/Ati on chip and dedicated ATI/Radeon cards. Any "suspicious" hardware/OS version tuple or have you seen this across the whole span ? Intel CPU screen on coming new cores is said to give a measurable boost - probably easier to tweak to find areas not hammered by Ryzen comparison.

And yes, calling DoEvents or other clean up stuff can degrade performance a lot if called too often.
My solution to the problem is to have different run scenarios :
[naked, C time profile, debug log, human eye]
which are guarded by a #define comparison (not even a function or method call lag) of current timing source [datetime(), seconds(), QueryPerformance] with a property of a global object which holds the time next action should occur first time again.

For human eye "next action" is either set to 10 sec, 1 min or 5 min, so at most 600 calls to the slowing down DoEvents, memory clean or whatever happen, which will not add a lot to total run time.

regards
thomas

>I have indeed seen this on a physical machine -- usually occurring (with some display drivers) whenever there might e a long-running loop -- either explicitly coded, or implicit (e.g. SQL query -- though the looping doesn't occur within the VFP interpreter, it still effectively within a loop in the VFP engine as it scans the tables). In such a case, a periodic scan of the event queue (such as using a command/function that implicitly scans keyboard/mouse event, or executing a DOEVENTS) would resolve this issue. With some drivers it appears that actual screen updates could get deferred (apparently to speed things up) until either the program gives up its timeslice (which would implicitly occur if it scans the event queue to check for input). As a plus, it also ends up help reduce the chances of getting the "this program is o longer responding" warning. You do have to be careful about this however -- use DOEVENTS far too often will cause the loop to take *much longer* to complete (i.e. it's not a good idea to do this every loop iteration) -- each DOEVENTS effectively causes your program to give up its timeslice.
>
>I don't recall if the state of LOCKSCREEN property on _SCREEN would affect WAIT windows or not.
>
>>On RDS I have seen this, but never on physical machine - that was reason for hint on driver.
>>On RDS heavy handed stuff like form move, or form hide and show sometimes cleared such issues up - not that they happened often, but for long running remote tasks every 5 minutes I included 1 such a call to verify by quick look if screen was "rather current" together with a "cleanup" call.