Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Unfortunately this is how "object oriented" code in AS2 works. This is how you should visualize it: when the timeline playhead is on frame A, and you call <code>gotoAndStop(B)</code>, the playhead is advanced immediately, and any necessary objects are created, but any timeline scripts you have on frame B are not yet executed, because Flash is still completing the execution of frame A. It's not until the next iteration of Flash's internal loop that frame B is processed.</p> <p>That's how things had been ever since the days when classes were just a glint in the proverbial milkman's eye. And as you can guess, with class-attached clips everything works the same - when you move the playhead to frame B Flash creates everything on frame B, but it doesn't run any scripts that reside on frame B - and this includes the constructors of clips that were just created - until the following frame.</p> <p>The easiest workaround is to rework your timeline so that the MC in question is created in frame 1, but kept hidden (or inactive, offstage, etc.) until the gotoAndStop command. You could do this by changing its alpha (etc.) in the IDE on the given frame, or by just calling an init method at the same time you do the gotoAndStop. The <em>best</em> workaround is to use AS3, if that's an option. There are other ways you can go, but I'd recommend one of those two.</p> <p><strong>update for edit:</strong> Yeah, one of the "other ways you can go" is to put parameters in the clip or its parent, and have the clip look for them when it initializes itself, but anyone who winds up maintaining your code won't thank you for it. But I've certainly done it. ;)</p> <p>In answer to your side question, a clip with _visible=false incurs a very small overhead if it's within the bounds of the stage. It is not rendered, but there is a very small hit, which I think has to do with Flash calculating its bounds or somesuch. (I ran a test once, and you really need thousands of them for it to be measurable.) Even if this is performance hit is a concern, the fix is to move the invisible clips outside the bounds of the stage. Then they incur no processor hit whatsoever, that I've found, they just use script memory (and if you delay their initialization until they're ready to be used, very little memory at that). </p> <p>Just remember that event handlers fire regardless of whether a clip is visible, so don't have your clip register for events until you initialize it. What I'd do is make an init() method with everything that belongs in the constructor, and call it where you would otherwise have constructed the clip.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload