home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Book HomeActionScript: The Definitive GuideSearch this book

13.4. Movie and Instance Stacking Order

All movie clip instances and externally loaded movies displayed in the Player reside in a visual stacking order akin to a deck of cards. When instances or externally loaded .swf files overlap in the Player, one clip (the "higher" of the two) always covers up the other clip (the "lower" of the two). Simple enough in principle, but the main stack, which contains all the instances and .swf files, is actually divided into many smaller substacks. We'll look at these substacks individually first, then see how they combine to form the main stack. (The stack in this discussion has no direct relation to the LIFO and FIFO stacks discussed in Chapter 11, "Arrays".)

13.4.2. The Programmatically Generated Clip Stack

Programmatically generated instances are stacked separately from the manually created instances held in the internal layer stack. Each instance has its own programmatically generated clip stack that hold clips created via duplicateMovieClip( ) and attachMovie( ). The stacking order for these clips varies depending on how they were created. Assigning depths to instances in the programmatically generated clip stack

You may be wondering what determines the stacking order of clips C, D, and E, or of clips A and F in Figure 13-3. The stacking order of a programmatically generated clip is determined by the depth argument passed to the attachMovie( ) or duplicateMovieClip( ) function, and can be changed at any time using the swapDepths( ) function. Each programmatically generated clip's depth (sometimes called its z-index) determines its position within a particular stack of programmatically generated clips.

The depth of a clip may be any integer and is measured from the bottom up, so -1 is lower than 0; 1 is higher than (i.e., in front of) depth 0; depth 2 is higher still, and so on. When two programmatically generated clips occupy the same position on screen, the one with the greater depth value is rendered in front of the other.

Layers are single-occupant dwellings. Only one clip may occupy a layer in the stack at a time -- placing a clip into an occupied layer displaces (and deletes) the layer's previous occupant.

It's okay for there to be gaps in the depths of clips; you can have a clip at depth 0, another at depth 500, and a third one at depth 1000. There's no performance hit or increase in memory consumption that results from having gaps in your depth assignments.

13.4.4. Stacks and Order of Execution

The layering of movie clips and timeline layers affects code execution order. The rules are as follows:

  • Code on frames in different timeline layers always executes from top to bottom.

  • When manually created instances are initially loaded, code in their timeline and load event handlers executes according to the Load Order set in the Publish Settings of a Flash document -- either Bottom Up, which is the default, or Top Down.

    For example, suppose we have a timeline with two layers, top and bottom, where top is above bottom in the layer stack. We place clip X on layer top and clip Y on layer bottom. If the Load Order of the document is set to Bottom Up, then the code in clip Y will execute before the code in clip X. If, on the other hand, the Load Order of the document is set to Top Down, then the code in clip X will execute before the code in clip Y. This execution order applies only to the frame on which X and Y appear for the first time.

  • Once loaded, all instances of a movie are added to an execution order, which is the reverse of the load order; the last instance added to the movie is always the first to have its code executed.

Use caution when relying on these rules. Layers are mutable, so you should avoid producing code that relies on their relative position. Strive to create code that executes safely without relying on the execution order of the clips in the stack. We can avoid some of the issues presented by the execution stack by keeping all our code on a scripts layer at the top of each code-bearing timeline.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.