Hiding the fact that a class is a DisplayObjectContainer

[IQAndreas]

I have a class which will contain exactly one child, no more, no less, and other classes are not allowed to change that fact.

I could throw error messages every time a child is added or removed by overriding the default properties, but I don't want the object to be treated as if it were a DisplayObjectContainer.

I want it to look like only a DisplayObject, yet I still want to add a child to it in private.

Is this possible?

[[MuG]]

I have NO idea why you would want to do this but wouldn't you just make the class extend DisplayObject and then type it as a DisplayObjectContainer when you need to add a child to it ?

I'm not even sure that would work...

[IQAndreas]

I wanted my class to display text, so I needed to add a textField to it, yet I didn't want anything else to be added to it via addChild, only whatever I controlled.

I realize now that by making the item seem like a DisplayObject only, the textField's parent property would mess up, since it's expecting it's parent to be a DisplayObjectContainer.

Another solution I thought about was rendering the text as BitmapData, and extending Shape, which is not a container.

I ended up extending textField for this project though, which definitely provided benefits.

[Krilnon]

The Loader class can also only have one child and it is still a DisplayObjectContainer. Also, it's not like a container that only holds one item isn't a container.

[cshaheen]

Method 1:

Create a DisplayObject class, pass it a reference to its singular child. Then use Event.ADDED and Event.REMOVED to add and remove your child instance from the parent class, ala:


addEventListener(Event.ADDED, onAdded);
addEventListener(Event.REMOVED, onRemoved);

private function onAdded(e:Event):void
{

parent.addChild(myChild);
myChild.x = this.x;
myChild.y = this.y; //may or may not need to copy more display properties
}

private function onRemoved(e:Event):void
{

myChild.parent.removeChild(myChild);
}



This way, your object acts like a proper displayobject (can be added, removed) and can have displayobject stored as it's "child". The only side affect is the additional child index in the parent container of your class, which may or may not break it.

[Felixz]

or override addChild() and addChildAt() methods to restrict to one child.

[IQAndreas]

or override addChild() and addChildAt() methods to restrict to one child.
For this project I just extended TextField instead, however, yesterday I did just so.

If anyone wants to do the same thing and not have to type a lot, here is the code for overriding all child handling methods:

// -------------------------------------------------------------------------
// OVERRIDDEN CHILD HANDLING METHODS
// -------------------------------------------------------------------------

//Users are not allowed to add children to the knob directly
//but must instead set the "displayKnob" property

//I used error number 2080 because it is similar to:
//Loader's 2069 error - http://iqandreas.blogspot.com/2009/09/error-error-2069-loader-class-does-not.html
//Stage's 2071 error - http://iqandreas.blogspot.com/2009/09/error-error-2071-stage-class-does-not.html


private function get oneChildOnlyError():Error
{
var err:Error = new Error("[VolumeKnob] Children cannot be added or removed from VolumeKnob. Please use the \"displayKnob\" property instead.", 2080);
err.name = "OneChildOnly Error [VolumeKnob]";
return err;
}

public override function addChild(child:DisplayObject):DisplayObject
{ throw this.oneChildOnlyError; }

public override function addChildAt(child:DisplayObject, index:int):DisplayObject
{ throw this.oneChildOnlyError; }

public override function removeChild(child:DisplayObject):DisplayObject
{ throw this.oneChildOnlyError; }

public override function removeChildAt(index:int):DisplayObject
{ throw this.oneChildOnlyError; }

public override function setChildIndex(child:DisplayObject, index:int):void
{ throw this.oneChildOnlyError; }

public override function swapChildren(child1:DisplayObject, child2:DisplayObject):void
{ throw this.oneChildOnlyError; }

public override function swapChildrenAt(index1:int, index2:int):void
{ throw this.oneChildOnlyError; }
VolumeKnob was the name of the class. Thinking back, I probably should have made the "oneChildOnlyError" system static, but it probably doesn't make that big of a difference.

Is there any standard in how errors should be numbered when creating custom errors? Perhaps any big database out there which stores error numbers?


Thanks for the input guys :)