>Hi Steve,
>
>>One thing is eluding me though, I'd love for this solution to work when I manage to get CreateObjectEX() working and the process is loaded into server memory rather than client. Is CHRSAW() or even MDOWN() going to work then? I haven't put this code in place yet, but will be this eve. In my search for a solution, I'm looking for the ability to be able to have a process running independently stop also.
>
>You're trying to create an interuptable process in a DCOM object ? I don't think this solution is going to work. You may consider the use of timers on the server object to achieve asynchronous processing.
>
>I've never done this before but the following might work.
>
>Create a DCOM scheduler object and a DCOM processing object. The first one does nothing more than scheduling the processing jobs, the second executes them.
>
>

>                        ------------------
>                       | Your Application |
>                        ------------------
>                                |
>                                |
>                        ------------------
>                       |    Scheduler     |
>                        ------------------
>                                |
>                                |
>                        ------------------
>                       |  Process object  |
>                        ------------------

>
>Your application cals the sheduler, which in fact does nothing more than schedule or discard processjobs. The scheduler itself has a reference to the processing object (fires the batched processes with the help of timers). During a process the process object checks if the process is canceled within the processloop. Most likely you'll batch the process commands into a table, so you can check very easely if a process should be aborted or not.
>
>Just think of it as the windows printer spooler.
>
>Good luck,
>
>Walter,

Walter,

Thanks....that's the whole issue here....an interruptable process in a DCOM object. I experimented with CHRSAW() last night. Why not just check for LASTKEY() being ESC? One problem is the controlling loop may have several processes that are performed. Putting CHRSAW() at the bottom of this loop means that all of these are going to run all the while the use is slamming the ESC key wondering where the cancel response is. CHRSAW() didn't seem to work well, or at least in my opinion. ON KEY LABEL suffers the same fate as ON ESCAPE commands. I did manage to get the default VFP escape dialog to come up, but this is not acceptable as it doesn't close out the application properly.

I'm not giving up, but I'm a little confused as to how MS is proposing to extend the SET ESCAPE ON / ON ESCAPE commands. ON ESCAPE won't translate an object reference, either THIS or some local instantiation. I have properties in the process that is running that when .F. will close out but I can't find a mechanism to set it when ESC is pressed.

Thanks,
Steve