As was mentioned, look for a halt command.
Another simple answer is, if you normally have the movie loop around, and you accidentally turned off the "loop" button on the control panel, then it will go once through the frames with sprites (unless you have a go to the frame command to force a loop) and when it runs out of sprite frames, it will call stopMovie.
It's a little hard to say without seeing the movie and/or knowing how it's structured.
I spent some time today trying to further debug my problem today with Gary Rosenzweig (who has an office a couple of blocks from mine).
What we found was:
* Nothing in my code appears to be telling Director to stop.
* If we put enterFrame, idle, and exitFrame handlers in the
framescript for the frame that dies, then we see that:
* I mistyped before and it is the chain of _enter_ frames,
_not_ exit frames that run prior to things shutting down.
* The app runs, you trigger the change to the Fatal Frame,
and it runs successfully for 4 frames. On the 5 time
through the frame, it makes it through the enterFrames
on my sprites, but does NOT call the on idle handler
and does call stopMovie and stop.
* When this runs in a projector, it doesn't stop/quit/exit
the projector. Instead, everything appears to be stuck in
an invalid state where even something that has an on mouseDown
handler that basically does a "go to <some frame name>"
causes a script error claiming "Handler not found: #go".
At one point, I managed (somehow) to also get into this
state in authoring mode. When that had happened, I
entered 'the movieName' into the object inspector and saw
that it was 'cardcontainer.dir' .. which is one of our LDMs
rather than 'main.dir', which is our root-level movie.
* It appears that perhaps it is causing some sort of internal
Director error during the drawing process that happens
in between the enter and exit frame handlers?A corrected trace would look like this:
* Iterations 1-4 on this frame run successfully, with
an exitFrame handler in the frame script that does a
'go to the frame'.
* exitFrame on the frame script for iteration #4 runs.
* enterFrame on sprite 1 runs (iteration #5 now).
* enterFrame on sprite 2 runs (iteration #5 now).
* enterFrame on sprite 3 runs (iteration #5 now).
* enterFrame on sprite 4 runs (iteration #5 now).
* ...
* enterFrame on sprite 26 runs (iteration #5 now).
* enterFrame on the frame script for iteration #5 runs.
* stopMovie runs.A final (for now) bit of information that might be interesting or useful would be that if we set a breakpoint in the enterFrame handler in the framescript right before it does a put to the message window to indicate that iteration #5 is happening, the Director tool bar already shows the movie being in a stopped state.
We're still totally stumped. This is a hugely important bit of code for me to get working, as I keep hearing that some of the ways that our app is architected (using LDMs, using multiple 3D sprites, each inside an LDM, etc) are causing some of the large performance issues that we're seeing.
- Bruce
[To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
