The release of Flash Player 10 introduces two new frame related event types. Event.FRAME_CONSTRUCTED, and Event.EXIT_FRAME are the two new event types. These two new event types add another level of control for making animation sensitive changes to display list objects. The purpose of this post is to illustrate when these event types occur within a frame’s life cycle. Details will discuss the order that the events occur relative to Event.ENTER_FRAME, Event.RENDER, frame scripts, and constructor code of children display objects.
To provide context to the discussion it’s best to start with the order of events that are fired during a frame’s life cycle. This list was made by creating a Flash test file and looking at the currentFrame property of a MovieClip with the different frame event type listeners.
- Event of event type Event.ENTER_FRAME dispatched
- Constructor code of children MovieClips is executed
- Event of event type Event.FRAME_CONSTRUCTED dispatched
- MovieClip frame actions are executed
- Frame actions of children MovieClips are executed
- Event of event type Event.EXIT_FRAME dispatched
- Event of event type Event.RENDER dispatched
Steps 1 and 2
Flash Player 9 introduced Event.ENTER_FRAME, which is dispatched every time the playhead enters a new frame and is tied to the frame rate being run by the Flash Player. Event.ENTER_FRAME functions in much the same way as onEnterFrame() did in AS 2.0. In step 2 constructor code for any display list children is executed. This includes any display list objects extending from the native display list classes of the Flash API. The order of these two steps is the same as it was in Flash Player 9. Nothing new to report here.
New to Flash Player 10 the event, Event.FRAME_CONSTRUCTED is executed. It’s important to remember the order for when this event is executed. At frame construction is the first time that it’s possible to start referencing newly added display list children of the MovieClip that is being listened to. This caused all sort of issues in Flash Player 9 after issuing a gotoAndStop call to a frame with display list objects that didn’t exist on the frame where the gotoAndStop call was made. Due to the fact that display list children had yet to be instantiated, targeting a display object child would return null the first time an Event.ENTER_FRAME was called after the gotoAndStop.
Steps 4 and 5
Steps 4 and 5 remain the same in Flash Player 10 as they did in Flash Player 9. First the frame actions of the MovieClip acting as a display object container are executed. Then the frame actions for display list children are executed. Note that in the Flash CS3 IDE the load order, a setting adjustable in publish settings panel, would affect the order that the display list children would execute their constructors and frame scripts. I haven’t found that dialogue in the Flash CS4 IDE publish settings, maybe Adobe removed it? In any case, by default, it uses a load order of bottom up in CS4. That means that display objects that are on a lower layer will have their constructor and frame scripts executed before display list objects on higher layers.
Steps 6 and 7
New to Flash Player 10, Event.EXIT_FRAME is executed in step 6. As it’s at the end of the frame life cycle, it would be good to use when there is a need to manipulate a display list object after its constructor and frame scripts have been executed.
Another possible use for Event.EXIT_FRAME is to replace calls in Flash Player 9 that were using Event.RENDER. Flash Player 9 introduced Event.RENDER, which according to Adobe documentation is dispatched right before the display list is scheduled to be updated. Depending on how one looks at it this may be true, as it’s at the end of the life cycle above, that would mean it’s at the beginning of the next frame life cycle. During testing for this article I found that according to the value of currentFrame on the MovieClip I had assigned all my listeners to, Event.RENDER was the last event to execute. In addition Event.RENDER first requires a Stage.Invalidate call before it is dispatched. On top of those two issues there were issues with dispatching Event.RENDER in the first few versions of Flash Player 9. Developers need to do sub-version detection of Flash Player 9 to ensure consistent behavior. For these reasons I suggest investigating Event.EXIT_FRAME to see if it works in place of Event.RENDER.
Despite the issues with Event.RENDER there are still times when Stage.Invalidate can be used. For example, calling Stage.Invalidate during mouse movements in Flash movies with a low FPS setting will smooth drag and drop animations.