> And since timeout objects get system calls as timeout object > generated in the beginsprite event would exist when the > startMovie call is sent out and if the timeout object does > not specifically trap for a startMovie call that gets passed > along to the movie script. The result is 2 startMovie calls. > > Note, I believe that if you jump from one movie to another it > is not just frame 1 that is the problem. Code like: > > _movie.go(10, someMovie) > > Will have the prepareMovie fire, then the beginsprite events > for sprites in frame 10, then the startMovie event. So you'll > see the same problem you see now even though you don't have > sprites in frame 1.
And we have a winner, there is no funky mojo at work here, just what's described above. If you have timeout objects alive when the startMovie event occurs you'll get this behavior - normally that pertains to frame 1, but intermovie navigation allows you to jump into a starting frame other than 1. FWIW, timeout objects have long received these system events and the behavior described is as intended and by design, this is in no way a bug (one might argue it's not optimal but as of today it's working completely as designed and expected [based on that design]). Rob's description and work-around are spot on. Cheers, Tom Higgins - Technical Product Manager Macromedia Director and the Shockwave Player http://www.markme.com/thiggins/ [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 lingo-l@penworks.com (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
