BWETTLAUFER wrote on Apr 16
th, 2014 at 9:57pm:
Hi Mark,
Yes, it's moves on to the next file to process the mass update.
Do you mean the next record or do you have multiple files it is processing?
Quote:I think an interrupt flag would be great. A time limiter is a good fallback, but occasionally a staff member stays late, and wants to kill the job when they leave for the day. Is there a way to check a keystroke that's buffered, or can you think of a simple toggle that could check an external text file, or some such thing?
Checking a keystroke is difficult for exactly the same reason it is difficult to interrupt a mass update using CTRL-SHIFT-End.
GUI programs, like Sesame client are either waiting on the "event loop" or are processing based on the last event. A mass update is a lot of processing in response to an event. It can check with the event loop to see if any events need to be dealt with, but doing so opens up the possibility that the user will make menu selections or keystrokes that will distract Sesame, rather than dedicatedly running the mass update. So we set a bunch of flags telling the Sesame window to ignore most events while the MU is running, and only check the event loop for the magic keystroke once per each top level record. A sudden interruption to a MU is usually a bad mistake, in that it may leave a record half modified.
If Sesame gets that keystroke, it should stop advancing the top level record soon afterward and interrupt the MU. But, even if that works, it may be better to let the MU run to completion, but simply skip doing anything more to the subsequent records. This can be done by checking if a file contains a flag, or exists at all, and then bracing the "main" program with a conditional. You could attempt to read the keyboard using @GetFromKeyboard and then forcing the current record to the last record to end the MU, or setting a global flag and doing nothing more to each record and letting Sesame advance to the end of the set.