Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
More on Cancel & Process stopping
Message
From
10/07/2000 13:04:48
Walter Meester
HoogkarspelNetherlands
 
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00389492
Message ID:
00390325
Views:
11
Hi steve,

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


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

The ON KEY LABEL, OR ESCAPE, won't get your there. It will fire in your application but will not in your DCOM object. Your application will be on hold as longs as the process is executing.

Therefore you'll need a strategy like the windows printer spooler.
- an application schedules a printjob in the windows spooler.
- The windows spooler instructs the printerdriver to print the document.
- You can instruct the spooler to cancel printing.

walter,
Previous
Reply
Map
View

Click here to load this message in the networking platform