Having some strange hurdles with the display list again in as3. I wanted to start black boxing out some objects based on sprite for a little game engine I am tinkering with. One of the things I am finding is that referencing parent objects does not work how I would expect. If I build a function that calls out to parent when the Sprite is added to the display list it works great, I can check the parent clip and see if it is a certain type of object that is a bit more specific than DisplayObjectContainer and throw out an error if it isn’t. The problem I ran into is, if I extend this class parent starts returning null. This really throws a wrench in my plans as I basically want this extended version of sprite to only be a child of one specific class that I can extend. If I can’t extend these then they are kinda useless.

My second approach moved to overwriting the functions addChild and addChildAt in the parent class. Unfortunatly I ran into an issue with this of not being able to make the parameters of the function a bit more specific. Making the child parameter be a class that extends Sprite gives an incompatible override. This makes some sense as some of the other functions associated with addChild may have specified stuff dealing with DisplayObject, but it prevents me from easily showing that this class expects a more specific kind of DisplayObject. Instead I end up having to use casting to check if the DisplayObject is indeed the type of object expected and throw an error if it is not. Not exactly nice for documentation purposes. Hopefully I can come up with a more graceful solution to this problem that I have not yet found.

After working with AS3 for a bit I finally have come to nice solution to a problem I have alway had with OOP design in flash. Animation gets sticky when you are animating everything with easing classes in nested objects. Alot of times you want one animation to be triggered when something else has happened in another clip. Passing around references to objects in a very large tree can get really sticky. It gets even weirder when you try to move things around. Because of this I usually build some kind off main controller instead of compartmentalizing and extending. The main controller starts getting a little hard to manage on bigger projects. The AS3 event model really help with that. Build one static EventDispatcher, pass it events, and let all the clips that need to listen for events do so without ever having to care what/who sent the event. This is not a crazy concept, just a way of looking at things, that I never did before. In some ways it is probably not the best approach for someone to pick up the files later and start working with them, as they would have to do a project search for the events being broadcasted and listened for, but it is less type errors and less adjusting when a group of objects is added to a new parent.

After doing a lot of this I figured, why not just make an AS2 version for myself for all those banners, and projects that require silly levels of player penetration. I have posted it here. It is nothing fancy, and could perhaps use stuff like bubbling and real events, but for now it seems to be serving my purposes.

Started having problems with some audio playing at weird times and events firing strangely in some swfs I had loading into a host clip. Really pissed me off and I didn’t really know what was going on until I saw this article. Cmon adobe. AS3 was supposed to make things simpler, not the usual haxxor your way around the weird player issues. addChild == nice. Having to force and animator to write disassemblers = not so nice. Didn’t take long to find a workaround once I saw this article, but my hours of struggling with Loader.unload() really sucked.

“visible” works a little differently in as3. Seems that it disables button actions and turns the alpha to 0, but keeps the item as part of the display list. This means that my old tricks of turning things visible = false then getting the parent size do not work correctly anymore. At first this was frustrating until I realized that removing an object from the display list is much more clear and effective.

It’s a slightly different way of thinking:

package{

  import flash.display.*;

  public class SomeObject extends Sprite{

    public function SomeObject(){
      super();
    }

    /**
     * Will add and remove the child object from the sprite if needed.
     * @param  targetChild  The child to add or remove.
     * @param  isVisible  Add or remove it.  Default is true.
     */
    public function setChildVisibility(targetChild:DisplayObject, isVisible:Boolean = true):void{
      if(isVisible){
        if( !contains(targetChild) ){
          addChild(targetChild);
        }
      }else{
        if( contains(targetChild) ){
          removeChild(targetChild);
        }
      }
    }
  }
}

As usual a tad bit more code, but a lot clearer about what results we want. The hardest part is the transition in a production environment where all the old shortcuts just don’t work anymore.

Looks like the flash 9 editor does not allow for the trick of using a bitmap pattern fill for scale9 slicing. Still seems strange to me that they would not encourage working with bitmaps for scale9. I’m happy I did a search, because I was about to write my own class before I came across this post. It does exactly what I wanted it to do: apply scale9 properties to a bitmap. This is something that is really nice about as3, lots more people are building compartmentalized little tools that can just be grabbed and plugged into your project.