>>>>I'm testing a long running vfp program and found these problems
>>>>
>>>>Wait window messages freeze (in different parts during different runs)
>>>>Added debugout message, but it also freezes.
>>>>I set escape on, but program doesn't respond to ESC
>>>>Added saving message to disk which shows that program continues to run
>>>>Finally process finishes correctly
>>>>
>>>>It's almost like it locks screen and keyboard out.
>>>>
>>>>I have windows 7 64 bit and VFP sp2. Any idea what may be the problem?
>>>
>>>Naoto and Rick have pointed out the most likely thing, that you need to periodically issue DOEVENTS during your heavy processing.
>>>
>>>I agree with Dragan's idea of using something other than WAIT as a progress display. For my long-running/unattended processes I do a lot of logging to text files, and I echo some of the log entries (including datetime) to the bottom of a scrolling editbox on a form.
>>>
>>>WAIT is something of an odd duck, present in the product since the DOS days. I don't know how it's been implemented in Win32 but I suspect it's a kludge. I avoid it if at all possible; if I need to use it I make sure to issue WAIT CLEAR when I'm done with it (or before issuing another WAIT).
>>>
>>>Long-running SQL queries block and can make the system unresponsive. Many years ago I was running large queries on slow hardware so I experimented with something like this:
>>>

>>>SELECT ;
>>>  ColumnsYouWant ;
>>>  , MyUDF( DATETIME( ) ) AS JunkColumn ;
>>>  FROM ...
>>>
>>>FUNCTION MyUDF
>>>LPARAMETERS ttDT
>>>
>>>* Run every 5 seconds, (pseudocode only, below won't work as-is):
>>>IF MOD( SEC( ttDT ), 5 ) = 0
>>>  DOEVENTS
>>>
>>>ENDIF
>>>
>>>RETURN Something
>>>

>>>Finally, there is the question of I/O to your disk/virtual memory subsystem. If your processing hammers the disk then your system as a whole (including UI) will be unresponsive, that's one of the weaknesses of current versions of Windows.
>>
>>Thank you Al and all for the insight and ideas.
>>
>>Issuing DOEVENTS periodically is not a complete solution, but it helps.
>>
>>Setting _VFP.autoyield = .T. seems to solve the problem but creates a risk if user clicks on an ActiveX object. Is this the only disadvantage of setting _VFP.autoyield = .T.? If there are no Activex controls alive is there another reason not to set _VFP.Autoyield = .F.?
>
>The default value is .T., if you had it set to .F. you must have done that yourself - why? Are you using ActiveX controls?
>
>VFP Help for "Autoyield" explains pretty well the results of setting it .T. or .F..

Actually, Autoyield = .F. is the default for Codemine, which I use. He does explain in the help, but I wasn't paying attention...