This content has been marked as final. Show 4 replies
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.
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?
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"
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:
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*
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.