Introduction
In pretty much any visual application dealing with multiple objects on the screen, you have to take in to consideration the arrangement of those objects; arrangement here meaning the relations of overlapping these objects have with each other, and when I say objects here, or pretty much anywhere else, I mean visual screen objects or instances such as movieclips, buttons and textfields. While working in Flash, you can control the overlapping through such methods as appropriately arranging layers in your timeline or taking advantage of arrangement options available in the Modify menu such as Send Backward or Bring to Front etc. This can be done with any symbol, text field or group allowing you to manipulate just how they appear on the screen in terms of overlapping - something which can be very important in your movie design.

Arrangement isn't restricted to the Flash authoring environment though. With actionscript you have similar control, being able to have direct control of how objects on the screen overlap by changing their arrangement or depth, as its commonly refereed to, from commands given in your code. In terms of actionscript, however, you only have control over MovieClip objects, Button objects and non-static TextField objects since those are the only screen elements which can be given instance names and therefore be referenced by actionscript. Groups and static text blocks will always remain at whatever depth they were when they were placed and arranged on the timeline (supposing you don't accidentally replace them, but we'll get to that later on).

Multiple Timelines
Before getting into how exactly you adjust and control the depths of such screen instances, its important to understand their relation to Flash and multiple timelines. All movieclips in Flash, as you probably already know, have their own timelines. These timelines are kept separate from other timelines and run independently of those other timelines including the one in which the movieclip (or current timeline) exists. This means that if a movieclip lives within a movieclip who's timeline stops, the original movieclip's timeline would not also stop. Well, not unless explicitly told to.

Along with this kind of movie play separation, you have a separation of visual objects within timelines as well. By this I mean that all objects within any one timeline are kept separate from objects within other timelines. These visual objects themselves are pretty much separate from each other to begin with, though the separation here, as you might have surmised, is in terms of depths. The depths of objects can only be changed in respect to other objects within that same timeline. This applies to both actionscript and when working in the Flash authoring environment. What this means is that if you have two movieclips, clipA and clipB and they each have their own clips within, then those interior clips depths can not be changed or rearranged in relation to each other. The only way to rearrange their depth positioning is if you rearranged clipA's and clipB's depths directly which would then of course rearrange everything within those clips either above or below the other. All of this is from the design of the timelines and their self-containment.

You can think of movieclips and their timelines in this respect as boxes. Lets say you are packing your things up because you're moving to a new home. First you put your shoes in a box, then put that box in a larger box for clothes. Then lets say you pack a box for your many toothbrushes and then stick that box in a larger box for bathroom items. So, when you get to packing the moving van, you stick the clothes box in first and then, on top of that, you put the bathroom box. If for whatever reason or another, if you wanted the shoe box in the lower clothes box to be above the toothbrush box (maybe you have a fear of loose bristles falling into your sandals), then you would have to either a) take the shoe box out of the clothes box and put it on top of the bathroom box, or b) just put the clothes box on top of the bathroom box instead. Since the boxes represent timelines, in Flash, solution (a) won't work since there's no real practical way to change the timeline in which a movie exists - something to be conscious of if you didn't already know it. Solution (b) would have to be the solution to pursue in terms of Flash and relates to the clipA/clipB example above. If for some reason that solution is not suitable, then it may be necessary to rearrange your clips so that they exist within the same timeline and can be properly arranged.

The Depth Concept
That brings us to what a depth really is to Flash in its internal workings and understanding. What that is, is a number. Depths in Flash are all handled through a simple number which indicates to the Flash player whether a visual object on the screen has a high depth or a low depth - whether its above or below other objects based on their depths. The higher the number, the higher the depth and the more likely that object is going to be above another. The lower the number the lower the depth and the more likely the object is going to be below another. Any object who's depth is greater than another object's depth will overlap that object. The reverse applies if the depth is lower. So, going back to clipA and clipB, if clipA has a depth of 10 and clipB has a depth of 11, then clipB will overlap clipA because clipB's depth is greater. Each object in a timeline has their own depth and no two depths in the same timeline share the same value. This way there is always a known depth relation between all objects in any one timeline at any given time. Basically, the depth of any object is just its stacking order - a number representative of how objects are positioned on the screen.

Flash determines the initial depths of objects by two means, you and you. The first method is through evaluating your layout in Flash authoring - how you arranged your clips and what layers they are in etc. Granted, you aren't given strict control of an actual numerical value here, but that arrangement does reflect the depth given to an object as its rendered in the Flash player. Secondly, if you use any dynamic instance creation methods, such as attachMovie or duplicateMovieClip, Flash will know the depths of those objects because it is required by you to specify those depths when those methods are called.

When Flash determines the depth of objects from the your layout in the Flash authoring environment, it does so for each timeline considering current overlapping arrangement along with layer positioning. Layers, however, are not referenceable through actionscript. For all events and purposes in regards to actionscript, layers are nonexistent in a swf. Where they were and how they were set up is completely oblivious aside from one simple number assigned to each and every instance that existed on those layers. This number, of course, being the individual depths of those instances. Flash in playing the timeline reads each layer and its contents interpreting them to a physical depth position and giving it a depth number based on its position relative to other objects in that timeline. Object instances in higher layers receive higher depths and those in lower layers receive lower depths. What layers were these objects in? We wont know - they're as good as dead to actionscript, but this of little consequence as anything we would need to reference has an instance name (providing one was given) and therefore is accessible to you. As Flash reads the timeline to assign these depths, it works from the lowest objects up, first drawing the lowest objects on the screen with the lowest depths then continues to the higher objects which are positioned on top of that. The starting depth in this procedure (the depth the lowest clip gets) is very low and will be touched upon later.

Depth Methods
The functions in Flash which pertain to depth, in some way or another, are:

The first 4, duplicateMovieClip, attachMovie, createEmptyMovieClip and createTextField involve dynamically creating new instances of screen objects on in a timeline in Flash during runtime. Using these methods requires that a depth be set for the new instance created, thus allowing you to order and arrange your new clips in the timeline as you see fit. If, however, you attempt to create a new object with one of these methods in a depth which is currently occupied by another instance, the new clip will remove that original instance to make room for itself. Because of this, you may need to be careful when specifying which depth you place new instances with these methods or you might lose other movieclips.

Following those is swapDepths which is used to change the depth of an object on the screen. This can be done in two ways, either exchanging the depth of the current clip with the depth of another clip or by specifying a number directly shifting the depth of the current clip to that numeric depth. In this manner swapDepths acts not only as a swapDepths but also a type of setDepth function as well. Unlike the previous methods, however, if you try to set the depth of an object to a depth currently occupied by another object with swapDepths, swapDepths will act less like a depth setter and more like the other form of depth swapper. The new clip will occupy the desired depth, but since depths cannot be the same value, the object at the lower depth is sent back to the depth which the original clip first existed effectively swapping the two depths. SwapDepths can also be used on levels, but only in the swapping sense and only for visual arrangement (in other words, you can't use number values for swapDepths when dealing with _levels, you need another actual level to swap with). What I mean by that is that if you swap level 1 and level 2, even though level 1 may now be on top of level 2, it is still known as _level1 and not _level2. Though, initially, levels are referenced in a manner which may relate to their arrangement, using swapDepths on levels will not change their naming.

The next in the list is getDepth, which, obviously enough, retrieves the depth of any movieclip, button or textfield object. Then there is removeMovieClip and removeTextField which is used to remove movieclips and textfields from the screen. These pertain to depths because there are certain depths, as you will see later, where these methods will not function properly.

As you can see, most of these methods work on movieclips. This makes sense, as it is the movieclips which have the timelines we need to be concerned about, but for something like swapDepths and even removeMovieClip, you may want these to be accessible to your TextField and Button objects as well. Truth is, they are, just not by default. What I mean by that is that those methods, which are contained within the MovieClip.prototype, can be just as well used for a Button or TextField object so long as that instance has access to the function, which, by default, they do not. Here's how to change that by adding those functions to be accessible to the TextField and Button objects by adding them to those prototypes:

Button.prototype.swapDepths = MovieClip.prototype.swapDepths;

TextField.prototype.swapDepths = MovieClip.prototype.swapDepths;

Button.prototype.removeButton = MovieClip.prototype.removeMovieClip;

// TextField already has removeTextField

Now these methods can be used in Button and TextField instances just as they can with MovieClip instances. Actually, you can even use other methods in these objects this way, like attachMovie. Want to attach a clip to a button? How about a textfield?

Next Page