4 Replies Latest reply on Jun 21, 2007 3:09 PM by Applied CD

    Stage sound quits when MIAW is dismissed

    Applied CD
      My stage is playing a sound in channel 1. Nothing fancy, not even puppetted, just a sound cast member placed in the score. The sound continues to play when I open a MIAW, but, when the MIAW is closed and focus is returned to the stage the sound stops, sound(1).isBusy() reports FALSE. The MIAW has a cancel button with the following behavior:

      on mouseUp me

      The stage has a public movie script with the following:

      on closePromptWindow

      BTW: Same results with a puppetted sound. Anyone know why this will kill the stage sound?
        • 1. Re: Stage sound quits when MIAW is dismissed
          Level 7
          It's a known issue. I just went to reference the TN about this, but it
          seems to have disappeared!
          In essence, the TN acknowledged that forgetting a MIAW kills all sounds
          playing and suggested closing any MIAWs and moving them offstage, but
          not forgetting them. It wasn't a very satisfactory workaround and TTBOMK
          the issue persists.

          BTW: despite claims to the contrary, I still think that forgetting MIAWs
          synchronously like you are is asking for a crash and have yet to see a
          TN/Readme from Adobe that states otherwise.
          • 2. Re: Stage sound quits when MIAW is dismissed
            Applied CD Level 1
            Thanks Sean, knowing it’s a bug I can probably find a work around.

            I’m curious about your statement:

            “closing MIAWs synchronously is asking for a crash”

            I’ve found that having MIAWs self close is generally unreliable; I get much better results if the MIAW sends a message to the stage asking to be closed and have the stage do the dirty work of actually closing the window, are you saying the reverse is more reliable?
            • 3. Re: Stage sound quits when MIAW is dismissed
              Level 7
              No, I'm saying that you're effectively still having the MIAW forget
              itself - all that your posted approach does it forget it by proxy; it
              amounts to the same thing.
              If you ever set a breakpoint or encounter an error and open the
              debugger, in the top-left pane of the window is a list of handlers in
              the order they called one another (if there is more than one listed).
              When one handler finishes it hands control back to the handler "above"
              it which then proceeds executing from the line where it called the
              handler that just finished.
              Now consider your scenario: you have a handler in your MIAW that calls a
              handler in another movie/window. This other handler forgets the MIAW and
              finishes (reaches 'end' or 'return' or 'exit'). Now the lingo engine
              needs to return to the handler that called the one that just finished.
              But the movie/window that contains this handler doesn't exist any longer
              - the window was forgotten. The lingo engine gets confused/corrupted and
              you /occasionally/ get a crash. This has often been likened to chopping
              off the branch you're sitting on and the analogy is a good one.
              When I said 'synchronously' I meant that somewhere in the current
              execution stack the window to be forgotten is referenced; and that this
              is dangerous. Here is a snippet I use to forget MIAWs:
              -- #parent script: "window.closer.class"
              property pWindow

              on new me, aWindow
              pWindow = aWindow
              t = window("stage").movie.timeOut().new(string(me), 0, #dummy, me)

              on prepareFrame me, aTimer

              on exitFrame me, aTimer

              -- #movie script in your window:
              on closeWindow

              The "trick" with this script is that it creates a timeout object in the
              context/scope of another window altogether, and the real forgetting is
              done by this timeout. Thus the window being disposed isn't referenced by
              the call stack *when the window is disposed*
              • 4. Re: Stage sound quits when MIAW is dismissed
                Applied CD Level 1
                Hmmm … I thought the stage and MIAWs maintained independent execution stacks, so the closePromptWindow handler would be added to the stage stack, not the MIAW stack, allowing the MIAW handler to finish regardless of what the stage was doing … HOWEVER … I did a quick test by having the MIAW tell the stage to call a handler with an infinite loop and sure enough, the MIAW sat around waiting for the stage to finish. (Come to think of it, I believe I’ve seen this behavior before when I tried to use an MIAW to make a “please wait while loading” progress bar … if the stage was busy doing its thing the MIAW never updated the bar) This behavior is a little puzzling to me because, after all, the MIAW didn’t call the handler, the stage did it, so why should the MIAW wait for a call back. I did a quick google search but couldn’t find any info on how Director manages the stack when MIAWs are involved, I guess it’s a single last in, first out list and everything except net operations are strictly synchronous.

                BTW: thanks for the code snippet … I’ll use that in the future.