No, I’m not asking that question. Instead, I am going to answer it and explain the reasons why it’s not as easy to traverse the display list like you could in ActionScript 2. In addition, I’ll give you a couple options for how to get around any errors you may encounter when you need to “hack” up and down the hierarchy. Under most circumstances, I don’t recommend them, but I believe that there’s nothing wrong with knowing what you’re not supposed to do.
Let me begin with a recommendation. If you’re just starting with AS3, and you’re a little frustrated with the extra work these language changes make you do, please consider taking a short time to learn a little object-oriented programming principles and how to do things properly. Why? Well, some important benefits come from coding through best practices. First, it’s easier to catch bugs because the compiler is much smarter than it used to be. Silly mistakes that might go unnoticed in AS2 will be caught immediately in AS3. Second, your code will run many times faster because the compiler makes special optimizations with well-written code. No one can argue that fast and bug-free code is silly. The new language is trying to help you to achieve those results, so don’t fight it.
Now, let’s put my preaching about best practices behind us. One of the first things a lot of developers familiar with AS2 may discover is that code similar to the following doesn’t work anymore.
this.parent.parent.some.deeply.nested.movie.clip.x = 50;
If you try to compile code like that in AS3, the compiler will throw an error:
1119: Access of possibly undefined property some through a reference with static type flash.display:DisplayObjectContainer.
The new compiler is a little bit stricter than it used to be in the AS2 days of Flash 8 and below. Today, the compiler knows that a MovieClip’s parent property is of type DisplayObjectContainer. It might actually be a subclass, like Sprite or MovieClip, but the compiler can only guarantee that it’s a DisplayObjectContainer. This class is not dynamic. To add new properties, like a child MovieClip that can be accessed publicly, you need to subclass it. In other words, if you instantiate a DisplayObjectContainer directly, you can’t do something like this:
var displayObjCtr:DisplayObjectContainer = new DisplayObjectContainer();
displayObjCtr.myDynamicProperty = 12; //error
On the other hand, the MovieClip type that we all know and love is dynamic. You can add properties and methods and anything you want to it without restriction.
var clip:MovieClip= new MovieClip();
clip.mySpecialVariable = "hello!"; //okay!
“…but,” you say to yourself, “I know the parent of my symbol is a MovieClip!” Good for you. The compiler doesn’t know that for sure. It’s possible to remove any DisplayObject from its parent and add it to another. How’s the compiler (which isn’t running all the code. It’s just making it into a SWF) to know that the parent hasn’t changed to a Sprite, CheckBox, or something else when you run your code?
Since you know the answer, that a certain parent is always going to be a MovieClip, then you can explicitly tell the compiler, “It’s okay. Please assume this is a MovieClip rather than a DisplayObjectContainer. Trust me.” This is called casting.
MovieClip(this.parent.parent).some.deeply.nested.movie.clip.x = 50;
Personally, I prefer the “as” keyword for most casting, but you may use either. Take the time to learn more about each because they behave differently in subtle ways. Here’s an example of casting using the “as” keyword:
(this.parent.parent as MovieClip).some.deeply.nested.movie.clip.x = 50;
Notice that you don’t need to cast the other MovieClips. That’s because the compiler assumes dynamic properties are of type Object, which is another dynamic class. Everything is an Object in AS3, so this is fine for our purposes. If you’re looking to optimize your code, you should consider casting them too. AS3 runs a little bit slower when it only knows something is an Object.
Let’s Get Crazy. Turn Off Strict Mode!
Now, some folks think the extra work of casting is a pain. If you must traverse the display list, I recommend using casting as much as possible to keep the compiler aware about variable types. Let’s consider, though, the possibility of coding like we could in AS2, with no casting needed and all the flexibility of the good old days. Sounds interesting, you say? Read on.
When you create a FLA file for ActionScript 3.0 in Flash CS3, you get all the strict typing checking by default, as we’ve all seen. However, at it’s core, AS3 is still a dynamic language, and you can tell the compiler to shut up if you want. Here’s how you do it:
-
Create a new ActionScript 3 FLA file.
-
Then go into the Publish Settings, either from the File menu or the Properties panel.
-
Under the Flash tab, click the Settings… button next to ActionScript version.
-
Uncheck the Strict mode checkbox
Remember that AS2-like code that gave us an error before? If you try to use it with strict mode turned off, the compiler won’t complain at all!
this.parent.parent.some.deeply.nested.movie.clip.x = 50;
It’s very simple to set up a FLA file to work with strict mode off, as you can see, and I’m surprised that I haven’t seen it mentioned before. I created a sample Flash CS3 FLA file with strict mode disabled if you’d like a hands-on look at how I set it up. You’ll discover that it compiles and runs without error, but if you go back into the Publish Settings to re-enable strict mode, you’ll get compiler errors. Have fun, and don’t come complaining to me when someone yells at you for turning strict mode off. I warned you to leave it on!
