Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
More on Cancel & Process stopping
Message
De
10/07/2000 13:04:48
Walter Meester
HoogkarspelPays-Bas
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00389492
Message ID:
00390325
Vues:
9
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,
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform