An amazingly detailed answer... I did try and beat the loop by clicking ok and then hitting cmd/period. Couldn't beat it. I like your suggestions for remedies. I will implement them but, at the same time, I'll put in the on shiftKey trapdoor as well... Jim
on 6/27/06 6:48 AM, Ben Rubinstein wrote: > 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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution -- www.TalentSeeker.ca www.HiringSmart.ca/ns www.KeepingTheBest.ca/ns <http://www.OwnYourFuture-net.com> Own Your Future Consulting Services Limited, 23 Shoal Cove Road, Seabright, Nova Scotia, Canada. B3Z 3A9 Phone: 902-823-2339. Fax: 902-823-2139 _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
