>Ed,
>
>>If you're running a long, noin-interactive process, it's likely not even checking to see if a UI Event has occurred - try adding a DOEVENTS in the loop to let VFP check for UI events during the loop. This won't help you interrupt a single, long-running query statement - VFPtries to check the event queue
>
>
> prevonesc = on('escape')
> prevescape = set('escape')
> set escape on
> querhalt = .f.
> on escape querhalt = .t.
>
>If you set this code before running long query, you would be able to interrupt query once progress bar shows up (set talk should be on for this).
>This code belongs to Mike Asherman and works fine.
If the Progress Bar is active, then VFP responds to UI events, doesn't it?
Like I said, if it's a long, non-interactive, non-UI code loop, VFP won't respond. I often decide that the better performance suppressing the UI is better than letting the user interrupt the runtime of loops and large SQL SELECTs. They can always start another session of VFP, or I can spawn the long operation to run a separate instance, with lower priority if necessary so the foreground VFP app stays responsive. Unless there's a good reason to stop the execution (not the user getting bored) why interrupt if you can work in parallel?
>I use the same technique for interrupting scan endcan process (or any loop) in a program.
>
>between statements, and within a tight loop in a single procedure, not running non-interactive code which is fully in-line without issuing a DOEVENTS (a call to an outside procedure will check as well). I'd add code in the loop something like:
>>
>>
IF CHRSAW() OR MDOWN()
>> DOEVENTS
>>ENDIF
>>
>>and have a key assigned to the Cancel action to handle a pending Escape. This also would handle the situation where a user Clicked on a Cancel button or a similar control. It's a matter of allowing VFP to check the event loop while running something which isn't inherently interactive.