>>>>UPDATE 2. Another question is how to deal with a user interrupting the process. The form has Cancel button which set the form property lExit to .T. And the Process code checks for this value. Of course, when the Process code runs in a Biz method, the form property is out of scope. Unless, again, I pass the form reference to the BIZ method. But I am thinking/looking for a better solution/approach
>>>
>>>You've already figured out the answer - pass the form as an object reference to the method e.g. LPARAMETERS toForm, ... . That solves the Cancel issue; where it currently checks for ThisForm.lExit = .T., instead it checks for m.toForm.lExit = .T.
>>
>>Yes, It does seem to work - passing the form as an object. However, when I click on the Cancel button (where for testing I put Messagebox), the click fires only after the entire procedure is done. That is, I see the messagebox() after the process is complete. And I do have DOEVENTS in several places in the code. But it does not seem to do anything.
>
>Hmm... I'm not sure why the behaviour would be different. Your code in a button click should run to completion before Cancel.Click() gets processed (and .lExit gets set .T.) unless there's something else going on you haven't already mentioned.
>
>If the form's Cancel.Click() is able to interrupt SomeOtherButton.Click(), exactly how is it doing it now?

Well, the flipside of having oodles of doevents could be other events slip in between previous and next code line.
Also IIRC at least on escape literally calls up an interrupt into running code, which timer code usually does not.

@Dimitry: If your code runs for more than .5 secs, you should consider either
disabling all possibly interrupting buttons at start and enable them again at the end
or
rewiting the long winded code to start again with changed parameters
Both approaxhes make sense in some use cases - not knowing your specifics impossible to tell from here