Ben, The situation (as I see it) is that the modal command (which is called by the answer box) stops script execution until the dialog box closes, at which point it continues. Therefore there is no "exit to top" capability (per se), that is, it would be the same as creating a button that just said "exit to top"... it would execute, but it wouldn't really do anything. Better yet would be to cancel the pendingMessages, and set a global variable or custom property that can be checked immediately after your answer box code... if it's been set, bail out.
Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ ----- Original Message ----- From: "Ben Rubinstein" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 09, 2002 2:27 PM Subject: Re: Abort in debug mode > on 9/4/02 11:39 AM, Terry Vogelaar at [EMAIL PROTECTED] wrote: > > > In the debug mode, I miss the ability to abort a script. When things go > > wrong, the only possibility is to run the script to the end. It is better to > > end execution of a script as soon as one knows where it goes wrong. > > (I agree, btw. When everything has stabilized and the Rev team can turn > their attention back to improvements, I certainly hope the Debugger is on > the list.) > > On a related note (I think - apologies if this is really a use-rev question) > "exit to top" does not seem to behave as one would expect if invoked in a > stack which was opened modal. > > I've long been irritated by the fact that you can't use the usual interrupt > method (ctrl/command-.) to interrupt a script when an answer dialog is up. > If you happen to have a loop processing a lot of data, which throws up an > answer dialog when it met an anomalous 'should never happen' case - and due > to some bug in code or data, it meets hundreds or thousands of such cases, > it's virtually impossible to break out the script without terminating > Revolution altogether (because it's so fast). > > Recently, working a shell which will host lots of different data processing > scripts, I wanted to create a dialog to alert users to odd bits of data, but > which would go away automatically after some period of time so that a long > batch wouldn't be held up overnight. I took a copy of the Rev answer dialog > stack and modified it to give it the timeout functionality I needed. Since > I now had my own answer dialog, I thought I'd avoid the problem noted above > by adding an 'emergency stop' button which could be used even if the > 'client' data processing script hadn't provided a clean way to break out of > the loop. So I added a little permanently visible button that canceled > pending messages and did 'exit to top'. > > To my surprise, what now happens is that the dialog appears, with a counting > down timeout to auto-OK. If I click the emergency stop button, it tells me > that it has stopped, and the timeout ceases. > > However, when I then click the OK button on the dialog, the script resumes. > That is, even when 'exit to top' has been executed, the act of closing a > stack that was opened modal "restarts" the script. No doubt there are > situations where this could be useful - but in the meantime, as far as I can > tell there is _no_ way to absolutely halt all pending activity (without > cooperation on the part of the code that invoked the dialog). I think this > is a bug - or at least a missing feature. > > If there is a way to halt everything, I'd love to know it. (And if there > is, can the command/control-period facility be modified to use it?) > > Alternative - would there be any way to tell that command/control-period > had appeared (eg an 'interrupted' message)? If there was, then the standard > answer routines could presumably use these to stop. > > Ben Rubinstein | Email: [EMAIL PROTECTED] > Cognitive Applications Ltd | Phone: +44 (0)1273-821600 > http://www.cogapp.com | Fax : +44 (0)1273-728866 > > _______________________________________________ > improve-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/improve-revolution > _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
