It's not a matter of getNextHighestDepth not working, it's a matter of controlling the depth to avoid unexpected behaviors. I've never had a problem with accidentally creating a movie clip at the same depth as something else, and that's one less thing I have to think about when debugging.
I find I get fewer unexpected behaviours the other way, but I attach things to the stage in the order I want them to appear, so scanning the code tells me the order that they are created.
The only time when setting depth constants was inconvenient for me was in a windowing system I built, in which case I built a window manager class that managed depth for me. The window manager class kept windows on a timeline where nothing but windows would ever be created, and always kept the depths of the windows consecutive, so when a window was closed it was swapped to the top before closing, and there were never gaps in the depths. I *could* have used getNextHighestDepth and saved myself the trouble of swapping windows to the top before closing them, but then if a user left the app open overnight and used it for several days in a row, they could theoretically open enough windows to hit the 65,535 depth limit and unexpected things could happen. So I went ahead and wrote the extra 10 lines of code to keep the depths consecutive, and circumvented the problem before it ever occurred.
Fair enough, reusing depths is a must there, and that's a nice solution. For the rest of the application, though, I personally would still use getNextHighestDepth(). Obviously you have a system that works very well for you, though, so stick to that. I will stick to this system because it works very well for me.
Nathan http://www.nathanderksen.com _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
