On 26/6/06 22:05, Jim Carwardine wrote:
> Yes, that's my problem... Cmd-period didn't work... And there appears to be
> no substitution remedy. I was developing a script and wanted to test a
> piece of logic inside a repeat loop so I put in an answer variable line as I
> always do. Then I got an answer dialogue with each iteration of about 1500
> iterations which was impossible when I couldn't abort the handler. BTW
> cmd/s doesn't work either... Jim
Hi Jim,
I don't think there's any problem with cmd-period in OS-X; but there is, and
always has been, a problem that cmd-period doesn't work if you've got a modal
dialog in the way.
The problem is that the modal dialog (which of course in Rev is really another
stack, with its own event loop) exists in another thread or "execution layer"
(I don't know technically how its implemented, I'm just trying to express how
it behaves.) So cmd-period works perfectly well as an interrupt; but if the
answer dialog is up, you're just interrupting that, and since it wasn't doing
anything anyway, nothing happens. Then you click OK, and you're back in the
stuck loop. If you were really, unfeasibly, quick, you could click OK and
then type cmd-period to the underlying stack before it throws up the next
answer dialog, and then you'd stop it OK. But typically in this situation,
Rev is too fast for you.
This applies as much to Windows and OS 9 as OS X; however, you do have a
couple more chances saving your data on the Mac, see below.
I've got into this situation many times, typically I have some data-processing
loop, and I think that I'd like to know if some situation that should never
occur does so. So I put in a "just in case" alert, click the button - and
then it turns out that due either to my misunderstanding, or erroneous coding,
the test fires on every one of 10,000 lines.
If I remember, I put in a 'hold down shift' emergency exit to escape from
loops like this. Increasingly, I've tried to train myself to put in
breakpoint for that situation, instead of or just after the "answer" call.
But of course from time to time I forget and get bit again.
Once when I was working on a shell that was to host a variety of data
processing scripts, I took a copy of the Rev answer stack, and modified it to
include a button that would do "exit to top" as a kind of emergency stop
button. It's so cool that in Rev you can do this... but unfortunately, it
didn't solve it. Just like cmd-period, "exit to top" when executed from
inside the modal dialog affected only that 'layer'. There seend as far as I
could tell to be no way to really halt the underlying script; it's suspended
when the modal dialog is invoked; but regardless of what happens while the
modal dialog is open, once closed the underlying script is resumed.
I set off a correspondence on the improve list, wait, let me see... just over
four years ago!... on exactly this topic, but we never found a good solution.
Unfortunately, this was before Bugzilla had been opened to the users, and so
nothing was entered anywhere persistent that might help.
So much for deep background. No doubt you've force-quit by now anyway. But
for future use:
a) cmd-period works in general just as well in OS-9 as in OS-X. But there's
no way to abort a script when an answer dialog is showing, unless you coded
for the possibility (ie 'answer xxx with "Stop" or "Continue"/if it = "Stop"
then exit to top).
b) I keep an applescript file handy called "Rev Saviours". It has a variety
of useful expressions in it which I uncomment and try when I'm in a situation
like this.
The one that helps here looks like this:
tell application "Revolution"
do script "close stack \"Answer Dialog\" ; save topStack()"
end tell
You'll still be stuck in your loop - but your stack has been saved, so as long
as you weren't worried about data in variables, you can force-quit with an
easy heart.
c) If you do have to resort to force-quit, make sure that you can see your
stack when you do it. In some situations on OS X, when Rev is force-quit it
briefly offers to save your stack - if you immediately click the button, it
really does do so.
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
