>
>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.

Thanks for the response, Ed. I knew it wouldn't be an inexpensive feature performancewise.