Stupid Send in Time Question

[Sarah Reichelt]

> I'm trying to do a timed presentation of images onscreen, so I end up with
> 45 lines of script in which pretty much every other line is a wait statement
> (do something, wait, do something, wait).
>
> Someone suggested I break the handler up into a bunch of little sub-handlers
> and use send in time and, remembering the oft-repeated list admonition to do
> this, I sat down to think about it.
>
> But I don't get it.  This will result in a script that's orders of magnitude
> larger as each showing will need to have its own subhandler for the sending
> in time.
>
> If I'm the only person running the stack in the IDE, is there any other
> benefit to be gained by adding all those additional lines other than not
> locking up the IDE when running the stack there?  Is there some better way
> to do it?

if you use "wait with messages", then it won't be too bad, as the
interface will not appear to be frozen i.e. the window can be moved
around the screen etc.
Resizing will not work as the resizeStack message will not be sent
until after your loop.

The "send in time" method can be done in a couple of ways.
You can have a series of handlers, with the last line of each doing
the send in time.
Or you can have a single handler with a script local or global
containing a counter. The handle could check the value of this
counter, so something based on the value, increment the counter, then
"send in time" back to the original handler.

However, if this is just a slideshow type thing, how about putting
each image on a new card, and using a handler like this:
command nextSlide
   go next card
   send "nextSlide" to me in 10 seconds
end nextSlide

Any additional scripting needed could be in the preOpenCard or
openCard handler for each card.

Cheers,
Sarah