> 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.
Sure I can do that (and in fact, I am doing exactly that) - but
- cancel the pending messages does not prevent the script
that invoked the dialog 'resuming'
- setting the global variable/custom property etc requires
cooperation on the part of the code that invoked the dialog
So my questions remain
- is there any way (could there be a way added) to _really_
cancel all pending code - including pending code that called
a dialog?
- is there any way (could there be a way added) to trap
"command-period" interrupts? OR, could it at least be arranged
that in the event of a "command-period" interrupt, all pending
code (including pending code that called a dialog) was cancelled?
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
> From: "Ken Ray" <[EMAIL PROTECTED]>
> Organization: Sons of Thunder Software
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 9 Apr 2002 20:56:16 -0500
> To: <[EMAIL PROTECTED]>
> Subject: Re: Abort in debug mode
>
> 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
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
