3 Replies Latest reply on Nov 5, 2006 2:13 AM by dave cragg

    Sequencing effects and delays

    dave cragg Level 2
      Say I want to do a sequence of things like this:

      1. Play effect
      2. Wait until effect is complete
      3. Do something (e.g. set text of a Text field)
      4. Play other effect
      5. Wait unil effect is complete
      6. Do something else (e.g. show an image)
      7. Wait 2 seconds
      8. Do something else (e.g. show other text)

      The problem is with steps 2,5,7. I don't see any way to "pause" the execution of script steps until an effect is complete or a Timer has completed. The only way I can see to achieve such a sequence of steps is to use effectEnd events (and the Timer equivalent). But the result is that the logic of the process is spread all over the script in various event handler functions.

      Perhaps I'm missing something. I'd be grateful if anyone could point me in the right direction.

      Or is uing effectEnd events (and the Timer equivalents) the only way to do this?
        • 1. Re: Sequencing effects and delays
          leotemp Level 1
          From what i understand yes.
          • 2. Re: Sequencing effects and delays
            peterent Level 2
            You got it. Flex is event driven - we love events.
            • 3. Re: Sequencing effects and delays
              dave cragg Level 2
              Thanks for the confirmation.

              I'm fond of events too, but I have to wonder whether the end of an effect is a bit of a non-event.

              Events are generally of some significance: a mouse click, a key press, or perhaps some threshold being reached in a game. They trigger a specific sequence of code, and their ocurrence is generally unpredictable, at least at the time you write the program. But an effect, once started, is predictable. It's going to end, and we know when. The only issue about effects is whether we want them to play synchronously or asynchronously. If we want them to play asynchronously, we have little interest in the effectEnd event. But if they always played synchronously, we would treat them much like a function or any single statement, and again wouldn't be interested in an effectEnd event. Wouldn't it be much simpler, from a scripting perspective, to have a way of flagging whether an effect should play synchrnously (like a normal statement), or asynchronously, and leave event handling for meaty events such as mouse clicks or asteroid collisions.

              Actually, I came across an example (in another context) of using nested functions as event handlers. I'm not sure whether it's a good solution to my original problem yet. I may just be swapping scattered logic for unreadable logic. But I'll give it a try.