>>>How can I do to stop a process pressing the stop button in a form.
>>>Ex. I execute a SQL statement and if I press the stop button, the process must terminate inmideatly.
>>>
>>
>>The problem is that you can't; VFP will not interrupt an atomic line of code for a UI event process to occur, and in many cases, will not recognize the event until the current procedure or method changes. You'd have to call a UDF with your SQL statement and force a DOEVENTS() to make it reliably interruptible.
>
>Ed,
>Please elaborate on your suggestion. I've been looking for ways to interrupt processes for years. Since we lost the ability to basically stop any process using the escape key in Fox DOS 2.6. Now if I realize the error of my ways in a command that is taking too long, I either have to wait it out or kill the VFP task. Neither choice is very good.
>What would you put in the UDF and where would you execute DOEVENTS()?

In the UDF(). The UDF might look something like:

FUNCTION MYUDF()
=DOEVENTS()
RETURN .T.

And instead of:

SELECT * FROM SomeDBF WHERE Foo = "BAR" INTO CURSOR MumbleBletch

I'd code

SELECT * FROM SomeDBF WHERE Foo = "BAR" AND MyUDF() INTO CURSOR MumbleBletch

You'll take a horrific performance hit, because MyUDF() is not Rushmore-optimizable and DOEVENTS() is expensive. You may find that you need to incorporate a reference to the UDF in the Select for a character field if you find that the evaluation delay for MyUDF() or the exclusion of the evaluation from the generated output results in not being able to interrupt work in GROUP BY or HAVING clauses that are the source of the performance problem that make the user insist on being able to interrupt the process.

I've found that in many case, simply relying on the workstation being able to spawn multiple instances of the app, each in its own VFP session, or moving the expensive operations to an off-line job server where users care that a long report is done, but don't want to stop while they wait on it to run, is a better long-term solution.