> The whole idea is that you keep > things at *predictable*, and whenever possible explicitly defined, depths > so > that things are easy to manage. If you need getNextHighestDepth, that > means > you don't know what the current highest depth being used is, and that > means > you aren't in control of the z-depth of your objects. That's a bad thing.
Yes, keep things predictable, and easy to manage. There are only two reasons you need control over the z-depth of your display object: 1) to visually layer your objects for appropiate overlapping of the items relative to each other. (usually after you z-position your objects to begin with you don't touch them again except in the case of floating windows or similar, which requires a 'put me on top' behavior) 2) to keep from accidently removing a display object through duplicate depths. I've also always had to know exactly what depths my display objects were, as I am generally more of the control friek. But I realized that I also lay out a lot of my visual elements in the Flash IDE and never seemed to care about the actual depth # in that setting. It was enough to know how everything was z-ordered the way I wanted in relationship to each other. I finally made my own DepthManager, which provides for extreme depths for cursors and tool-tips like MM's vs2 components, but without screwing up getNextHighestDepth() for those who would still use it. ( API: MovieClip.bringToFront(); MovieClip.bringForward(); MovieClip.sendBackward(); MovieClip.sendToBack(); where MovieClip.bringForward(); MovieClip.sendBackward(); can have one parameter, either of type MovieClip or type Number MovieClip: brings the calling MC directly in front of the argument MC, or sends directly behind Number: brings or sends calling MC forward or backward x number of steps. In the case of a 0, bringForward(0) would bring the MC to the front, sendBackward(0) to the back. In the case of a negative number, bringForward(-2) would bring the MC to the front minus two, or 3rd from the top of the visual stacking order. this provides for complete control in arranging visual objects in any order, relative to each other by name and/or by stacking order. I've never needed to know or care about keeping track of depth numbers since, though that doesn't mean I don't keep track of z-order (relational). And frankly I don't have the time or patience anymore to always be managing depth details when there's so much more to worry about. I would hate having all of my classes cluttered with two properties for every one visual object. private var vScroll:ScrollBar; private var vScrollDepth:Number; I'll try and get my code cleaned up a bit (I've been bad and not fully commented the class) for anyone interested. It will still allow you to set depths explicitly, as well as a padding that is currently at 2 or 3, but could be changed to 10. To be honest, I haven't yet found an instance where I've needed the depth number explicitly, but it's available. This and other classes that simplify implementation are one of the best ways to keep your code clean. Tyler ps oops, didn't realize I wrote so much. _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
