Starting in ActionScript 2, Adobe introduced a new public function available to the MovieClip class called addFrameScript that essentially allows ActionScript to be placed direct on a frame similar to just injecting it into the Flash movie’s (FLA) timeline via the Actions window. There are quite a few pros to be had with using this method, but Adobe mysteriously does not seem to support this method in their AS3 documentation:
But before we get into the cons, let’s start with how it’s used and why this method is potentially useful:
//must have a timeline with at least one frame (totalFrames)
public var someAlreadyLoadedClip:MovieClip;
//the currentFrame of the MovieClip is one greater than the index used to inject the script, thus the “-1″ at the end of totalFrames
//scope is not relevant when called within the same class
//note, parameters and return values are not required for the called function
public function calledFrameScript():void
Why this works:
- In programming it is essential to have assets separated from actions so that the programmer has full control of the applications mechanics. Inserting code directly into a timeline breaks this rule as the MovieClip is now bound to those actions on the frame and retains thoses properties when used as an asset. A programmer has limited control when it comes to changing the behavior of those assets from their compiled form.
- In Flex development, embedded SWF assets with timeline code typically lose much of their functionality and can be difficult to trace the problem. Using addFrameScript on the loaded, embedded asset can prevent this for complicated gotoAndPlay/gotoAndStop as well as just injecting standard stop() or play() calls
- You can reduce or completely remove the dependency of linked MovieClip symbols in the library by using addFrameScript to inject functions when specified frames are played or stopped upon an ENTER_FRAME event
- The delay between a changed symbol being completely available on a new MovieClip frame triggering the ENTER_FRAME event is not an issue when using addFrameScript instead (i.e. someClip.addEventListener(Event.ENTER_FRAME, onEnterFrame) vs. someClip.addFrameScript(someFrameNumber-1, callFrameScript))
What goes wrong:
Those are pretty good reasons to use addFrameScript as a serious, ActionScript developer, however, here is the one major problem I found with using it that does not have a work-around solution. Using the Flex Builder 3 Profiler, available on the Professional release, a collegue and I found that the memory of assets loaded and given an addFrameScript somewhere within it’s frames did not fully release their symbol on destruction. I created a small test project that had just one addFrameScript on one loaded MovieClip, simply telling it to “stop()”. I implemented a timer to destroy the clip and nullify it after five seconds and took a profiler snapshot of the allocated memory and Symbol available. To my disappointment, the MovieClip was still being allocated some space, despite using every method I know of to remove it. The major problems with this comes with building large-scaled applications that require the continuous destruction of assets to free Flash Player memory and ensure the application runs at peak performance. Without deallocating that memory, many large applications that would rely on addFrameScript would start to slow down considerably after extended use and eventually crash the browser. Unfortunately, there is no matching “removeFrameScript” hidden within the MovieClip API. If there was, it would have definitely been added to address the one major upset to this undocumented gem.
Categorised as: Flash ActionScript