> >On Mon, 26 Jul 1999, Andu wrote:
> >
> >> I found the only way to interrupt a repeat loop do some stuff and continue
> >> it afterwards is to open a modal window. Is there a way to do this just
> >> from scripting with no additional window?
...and Scott answered:
> >What is "some stuff" that you're trying to do? And what is being done
> >in the repeat loop that takes so long? Maybe there's a way to break
> >the loop up into separate handlers and use send .. in to call them...
> > Regards,
> > Scott
...and Andu again:
> The repeat goes through a text in a variable and if it finds words with
> certain characteristics I want it to stop, allow me to change those
> characteristics and then go on to the next words.
> Imagine a speller looking for misspelled words in a text, stopping when it
> finds one and continuing after some input from the user.
> I considered your suggestions but I decided the "cleanest" solution was
> using the modal window.
Scott: Using the modal command seems like it would be a good way to do this.
> I just hoped there was something I didn't know.....in terms of interrupting
> a repeat temporarily.
> Maybe there should be something like "stop repeat....resume".
...to which Scott responded:
If we did add something like this, it probably wouldn't be limited to
"repeat", but should allow interrupting any handler. Something like
MacOSs "cooperative multithreading" comes to mind, in which case you'd
use "yield" to switch to some other "thread" or return control to the
main event loop. The problem with this (and the biggest problem with
MacOS threading) is that your scripts could end up spending most of
their time switching among the threads and checking whether to
continue instead of getting real work done. This wouldn't really be a
problem in your spell checker example, but would be if you tried to
use it for certain other kinds of background processing.
If you want to discuss this further, I recommend restarting the
"thread" about this on the xtalk list...
Regards,
Scott
I understand your concern but...I don't think we need to interrupt just
*any* handler. To keep some sense of order we can limit this feature to
most useful situations (like mine ;-)). For background processing if it
comes to that , one can learn to be efficient or ...not.
Regards, Andu
