Blog

Dude, is this a bug in AS2? I’m probably doing it wrong.

In the main timeline, I can do:

function Mammal(target)
{
        this.target = target;
}

function Cow(t)
{
        super.apply(this, [t]); // doesn't work
        super.apply(super, [t]); // doesn't work
        super.call(this, t); // doesn't work
        super.call(super, t); // doesn't work
}
Cow.prototype = new Mammal();

It doesn’t even compile in AS2:

class Mammal extends Cow
{
        function Mammal(t)
        {
                super.apply(this, [t]); // says there is no apply method
                super.call(this, t); // says there is no call method
        }
}

I’m guessing this is because inside the constructor, it’s scoped to the function vs. “this”, where this is the class.

Typically, I’ll do:

function MyClass()
{
        init.apply(this, arguments);
}

So if the init method has a lot of arguments, I don’t have to type them out 3 times; twice in the constructor, and then again in the init. I figured I could just bypass init, and use super… but I guess he’s weird…? I’m confused.

Lemme get that for you. Typically the documentation explains these as “object creators” which is kind of… well, generic. They do more (or less) than that, and they are a lot more approachable than the docs lead on. They are, however, integral that you learn when you mess with the framework, for if nothing else, to kick it good form style. I don’t know everything, but here’s what I do know.

createObject

Replacement for attachMovie in the Flash MX 2004 component framework. A wrapper function for attachMovie, it operates the exact same. It returns whatever attachMovie returns; typically the movie clip/component object your attaching. You pass in the same parameters.

destroyObject

Replacement and extension for removeMovieClip in the Flash MX 2004 component framework. A wrapper function for removeMovieClip, it extends it to support authortime clips as well. Since authortime components (objects manually dropped on the stage at authortime) are automatically compiled to reside in negative depths, removeMovieClip will not work on them. This method, if it detects an authortime component trying to be removed, will find a depth that is unoccupied and empty, bring the component to that depth, and remove it. Finally, it deletes a reference to the movie clip’s name (no clue why since you just removed it).

The difference with this method vs. removeMovieClip however is that it takes a string parameter; the movie clip/component’s name as a string. Therefore, instead of doing:

my_lb.removeMovieClip();
// or
removeMovieClip(my_lb);

You’d do:

destroyObject(my_lb._name);

The framework itself uses this method because there are a ton of string references to objects in the other classes because of skinning, for example. Still, that’s not enough for me to understand why they did it this way. Maybe Java’s Swing does this… :: shrugs ::

createClassObject

An replacement and extension of attachMovie in the Flash MX 2004 framework. Typically, you use similiar to attachMovie, except you use your class name. For example:

var ref_lb = createClassObject(mx.controls.List, "names_lb", 0);

The first parameter, however, determines how the function works. Most classes created to work in the Flash MX 2004 framework will have a 2 static variables defined called symbolOwner and symbolName. The symbolName one represents a string pointing to the component’s linkageID. The symbolOwner is a reference to the class’s class name, or package path. In List’s case, that is mx.controls.List; the object on global that holds his class definition.

This function assumes if the class you pass in doesn’t have a symbolName, then it must be a sub class. Since this function calls createObject, and thus attachMovie, your creating a movie clip and getting a reference to it. The way Flash 6 & 7 associate class methods with a movie clip is via the method Object.registerClass. This takes the movie clip’s symbol linkage name (got that?), the class, and basically says, “Yo, if you ever get attached, you’ll now have all the powers of this class; properties, methods, you name it.” This can get weird if your class doesn’t inherit from MovieClip somewhere up the chain… at least in wrapping your head around the concept, anyway.

Therefore, if your class is a sub class, it’ll register it via Object.registerClass with the class’ symbolName/linkageID. After attaching the component/movie clip via createObject, assuming you passed in a sub-class, it does the registering again with a slight difference; it uses the className’s symbolOwner/class name instead of just the className you passed in. Not sure of the significance of the difference.

Conclusion

These are support methods, really, for a lot of the framework. Additionally, you can now see where the symbolName and symbolOwner static variables you may have been defining in your components are used. If these methods don’t work, it’s probably because those variables are not defined or miss-spelled. I’ve copied and pasted classes before to save time in rewriting a new class. I sometimes forget to change these variables with the class name.