Learning ActionScript 3.0: Chapter 4, The Display List
Pages: 1, 2, 3, 4, 5, 6

It is important to note, however, that, unlike 4-2, this is not a hierarchical depiction of an actual display list. For example, it is possible for shapes, bitmaps, videos, and static text, among other items, to exist inside movie clips. Yet in the diagram in 4-3, MovieClip appears to be lowest in the display list hierarchy, making this seem impossible in the traditional flowchart sense.

The key to this apparent dichotomy is that the display list classes originate with the DisplayObject class, and the flowchart shows the descendents of that class. Figure 4-3 is hierarchical, but it shows the possible objects that can be a part of any display object. Because a display object is anything that is, or can be, part of the display list, this flowchart is valid not only when examining the contents of the stage, but also when examining the contents of a movie clip, for example.

Here is a quick description of the classes in 4-3, rearranged slightly for clarity of discussion.

DisplayObject

Anything that can exist in the display list is a display object, and more specialized classes are derived from DisplayObject.

Shape

This is a rectangle, ellipse, line, and so on, created with drawing tools. New to ActionScript 3.0, you can now create these at runtime.

Bitmap

This is an ActionScript bitmap created at runtime using the BitmapData class. Note that a standard JPG import does not create this kind of bitmap, but rather creates a shape. After creating a bitmap with this class, however, you can place an imported JPG into it for display.

Video

This is a video display object, the minimum required to play a video, rather than a video component.

InteractiveObject

This class includes any display object the user can interact with using the mouse or keyboard. It is not used directly to manipulate the display list. Instead, you work with its descendents.

Skipping a bit, temporarily, and moving down a level:

SimpleButton

This class is used to create a button that's functionally equivalent to the buttons you probably have experience with in the authoring interface. However, in ActionScript 3.0, you can now create buttons on the fly by using other display objects for their up, over, down, and hit states.

TextField

This class includes dynamic and input text elements, controllable with ActionScript.

DisplayObjectContainer

This class is similar to DisplayObject in that it refers to multiple display object types. The difference here, however, is that this object can contain children. All display object containers are display objects, but only display objects that can have children are display object containers. For example, a video is a display object, but it cannot have children. A movie clip is a display object, and it can have children, so it's also a display object container. Usually, you will work directly with this class when traversing the display list, looking for children or ancestors. Usually, you will manipulate one or more of its descendent classes.

There are four kinds of display object containers:

Stage

Remember, the stage itself is part of the display list. This class demonstrates that any interactive object can reference the stage which, itself, is a display object container.

Sprite

New to ActionScript 3.0, a sprite is simply a movie clip without a timeline. Many ActionScript manipulations typically performed using movie clips only require one frame of the created movie clip's timeline. So, the size and administrative overhead of the timeline is unnecessary. As you become more accustomed to ActionScript 3.0, and begin to consider optimization more frequently, you may find yourself using sprites more than movie clips.

Loader

This class is used to load external assets destined for the display list, including bitmaps and other SWFs.

MovieClip

This is the movie clip you probably know and love, as a result of creating them in the authoring interface, via ActionScript, or both.

This excerpt is from Learning ActionScript 3.0. Learning ActionScript 3.0 gives you a solid foundation in the Flash language and demonstrates how you can use it for practical, everyday projects. The book does more than give you a handful of sample scripts, defining how ActionScript and Flash work. It gives you a clear look into essential topics such as logic, event handling, displaying content, migrating legacy projects to ActionScript 3.0, classes, and much more. Written for those new to the language, this book doesn't rely exclusively on prior knowledge of object-oriented programming (OOP). Instead, it helps you expand your skillset by first focusing on clear, concise examples in the timeline, evolving into OOP examples over time-allowing you to choose the programming approach with which you are most comfortable.

We left three items from the second tier for last, as you will probably use these classes the least often:

AVM1Movie

This class is for working with loaded SWFs created using ActionScript 1.0 or 2.0. AVM1, (which stands for ActionScript Virtual Machine 1) is reserved for SWFs that use ActionScript 1.0 and/or ActionScript 2.0, while AVM2 is used for SWFs that use ActionScript 3.0. Because Flash Player uses two discrete code bases, these virtual machines are not compatible. The AVM1Movie class provides a way of manipulating display properties of legacy SWFs, but does not facilitate communication between ActionScript 3.0 and older SWFs. This must be accomplished by other means, such as LocalConnections. We will discuss these other methods in .

MorphShape and StaticText

These two classes represent a shape tween and static text element, respectively, neither of which are controllable directly via ActionScript. However, they are part of the display classes because they inherit properties, methods, and events from their DisplayObject parent class. This makes it possible to rotate a static text element, for example.

Once you begin using the display list frequently—especially if you are familiar with the ActionScript 2.0 method of doing things—you will quickly become enamored with its power, flexibility, and simplicity. We will show you how to perform several common display list tasks in this chapter but, if you take one thing away from this initial discussion, it should be a basic understanding of display object versus display object container. To demonstrate this effectively, let's look at a short segment of code that traces requested content of the display list to the output window.

Displaying the Display List

It's sometimes useful, especially when you're creating many display objects with potentially complicated nested objects, to walk through the display list and analyze its contents. This little function, found in the companion source file trace_display_list.fla will trace the contents of any display object.

1 function showChildren(dispObj:*):void {
2    for (var i:int = 0; i< dispObj.numChildren; i++) {
3         var obj:DisplayObject   = dispObj.getChildAt(i);
4         if (obj is DisplayObjectContainer) {
5             trace(obj.name, obj);
6             showChildren(obj);
7         } else {
8             trace(obj);
9         }
10     }
11 }
12
13 showChildren(stage);

Lines 1 and 11 define the function showChildren(), which requires as its argument the display object you wish to analyze. (See the adjacent note for more information on the use of the asterisk datatype.) Line 13 calls the function and, in this case, passes in the stage for analysis. In this example, the function will trace the contents of all children of the stage.

Lines 2 and 10 define a for loop, which will loop until there are no more children in the display object passed into the function. The number of loops is determined by the numChildren property, which returns an integer representing the number of nested display objects in the object being analyzed. Each time through the loop, line 3 populates the obj variable with the next child in the display list using the getChildAt() method. This determines the child display object at the level indicated by the loop counter (i). The first time through the loop, when i is 0, the first child will be returned. The second time when i is 1, the second child will be returned, and so on.

Line 4 is what makes this function handy. It first checks to see whether the display object currently being analyzed is also a display object container. It does so by using the new is operator, which checks the data type of the object in question, comparing it against the DisplayObjectContainer type. This is important because if the display object is not a container, the walk through is over for that portion of the display list. The if statement will evaluate to false, jumping down to lines 7 and 8, and the object will be traced. The conditional then ends at line 9, and the code increments and goes through the loop again.

If the display object is also a container, it may have children, so the walk must continue down through that branch of the list. The if statement will evaluate to true, and the object (along with its name, in this case) is traced at line 5.

Finally, at line 6, the function calls itself again. passing in the object currently being inspected. This concept is called recursion. A function calling itself may seem redundant, but it can be very useful. In this case, each time the function is called, it receives a new display object to analyze, so the function reports the contents of that specific display object. The result is a complete walkthrough of all display objects, no matter how many children each may have.