The Problems with Managing Depth in ActionScript
Riddle~
Is it important to keep track of depths in ActionScript for all of my display assets? It’s something extra to worry about, but there’s always the danger of killing something by overwriting the depth. It’s also important to have control on what graphics go in front of others. The “right way” is to have those depths explicitly defined along with each element so it’s clear who has what depth and it keeps the children from fighting. But then that doesn’t work for graphics placed on the stage at design time.
Answer:
Relational depth management.
This means, though it goes against all you believe, that you don’t track depth numbers. MovieClips, Buttons and TextFields are arranged around each other. This one goes in front of that one. That one goes behind these two.
This will sound flawed if you have been managing your own depths for a while. It feels like a bad practice. But when it comes down to it you have enough to keep track of, such as what your code is supposed to do (your model), to worry about managing one more interface detail. If you just try it out in a real-world setting it won’t be long before you’re hooked. If you haven’t been forced to manage depths a lot, then this will save you that hurtle so you can focus on learning more important “best practices”.
The XT DepthManager adds 5 public functions to the MovieClip, Button and TextField prototypes:
getNextDepth()
bringToFront()
bringForward([target])
sendBackward([target])
sendToBack()
Most of these are obvious from their names. They’re relational, so bringForward doesn’t move a MovieClip up one depth, it brings it in front of the graphic directly in front of it (even if both were placed on the stage during author time). The Flash IDE has a direct equivalent that most designers are familiar with, and it behaves identically. The one difference is the target that can be specified in the bringForward and sendBackward methods. This is where the real power of this solution lies.
target can be a visual element (MovieClip, Button or TextField), or a positive or negative number. bringForward will bring a MovieClip directly in front of the asset specified by target, while sendBackward will send it directly behind. A positive number in bringForward jumps n elements forward, and sendBackward jumps n elements backward. For example, my_mc.bringForward(3) moves my_mc in front of the 3 MovieClips directly above my_mc. my_mc.bringForward(1) is the same as my_mc.bringForward().
Still following? So last of all, a negative number passed to bringForward will actually start at the front of the stacking order and move back -n number of spaces. my_mc.bringForward(-1) will bring my_mc all the way to the front of the line minus one position, so ending up second in line. Consequently my_mc.bringForward(0) is the same as my_mc.bringToFront(). Using negative numbers in sendBackward will send the visual element to the back of the line minus n, or moving up. This concept can be difficult to understand at first. It is comparable to negative numbers used in String.substr(). Once these simple calls are understood, however, you have ultimate control in relational depth management.
The XT DepthManager is an efficient relational manager. It eliminates the depth complexities from your code and maintains good performance, adding < 1.5 KB to the total size of your SWF. For large numbers of assets in one parent, such as a listbox cell parent, it is still smart to set depths explicitly by number because it's faster and they correlate directly to an index, so you always know exactly where they're at. In these situations you don't care about stacking order anyway.
The class available above is the basic relational depth manager which is compatible with Flash Player 6 and up. It will perform better in FP 7 as it takes advantage of MovieClip.getNextHighestDepth().
There is also a variant of the manager which additionally replaces the MovieClip and TextField creational methods (such as MovieClip.attachMovie() and MovieClip.createTextField()) so that depth management is abstracted (hidden) right from element creation. Never worry about depth issues again!
August 13th, 2008 at 2:01 pm
Hi, Does this work with negative timeline depths? Those in the -16,000 to -1 range? Also, could you post an FLA file with the zip showing how to import this ? I get the error : “‘com.codext.utils.Prototype’ could not be loaded.”