AS3: Impossible to copy DisplayObjects with content?

Question

How to copying display objects (sprites, movieclips etc) while keeping thier content (graphics, added display objects etc)in AS3? The most commonly suggested solution by Kirupa (http://www.kirupa.com/forum/showpost.php?p=1939827&postcount=172) doesn't seem to copy any graphics or child display objects:

// create a sprite
var s:Sprite = new Sprite();
// add a text field
var tf:TextField = new TextField();
tf.text = "nisse";
s.addChild(tf);
// draw something
s.graphics.lineStyle(1, 0x00FF00);
s.graphics.drawCircle(10, 10, 10);
s.x=100;
// add it to parent
this.addChild(s);       

// create a copy using Kirupas duplicate display object solution    
var sCopy:Sprite = duplicateDisplayObject(s, true) as Sprite;
sCopy.x = 200; 
// confirem that the copy exists:
trace(sCopy);
// add to parent
this.addChild(sCopy); // <- works, but the original textfield and graphics are gone!

Is there a sloution to this? (If not - Why? Isn't a display object represented by a memory area that should be possible to copy, like any other object?)

Answer 1

That's because AS3 is trying to be an Object-Oriented language, and the OOP way of doing what you are trying to do is to create a class with a clone method() :) I think this would be the most flexible, bug-free and easy to read way of copying your object.

Answer 2

You cannot natively copy most of the internal classes, but you might want to look in to IExternalizable (http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/utils/IExternalizable.html)

It is the method of serialising objects used internally by AMF. It forces your objects to create two methods, readExternal and writeExternal. The idea is that writeExternal allows you to package up the objects internal state in a ByteArray, then a new instance of your class is created, and AMF will pass that ByteArray in to the readExternal method, where you can recreate the previous objects internal state by hand. The calling of the methods and instantiation is all done for you through the ObjectUtil.copy() method (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/utils/ObjectUtil.html?filter_flex=4.1&filter_flashplayer=10.1&filter_air=2#copy()) if you're using the Flex SDK, otherwise, the copy implementation is as follows:

function copy(value:*):*{
  var buffer:ByteArray = new ByteArray();
  buffer.writeObject(value);
  buffer.position = 0;
  var result:Object = buffer.readObject();
  return result;
}

As you can see here, it's only the readObject and writeObject methods of ByteArray that actually do the serialisation, there is no real need for the ObjectUtil class.

You may also need to register a class alias for the class you want to copy so AMF knows what object to create, otherwise you will just get generic Objects out the other end:

registerClassAlias("com.example.ExampleClass", com.example.ExampleClass);

It should be noted that you cannot have required parameters in the Constructor of objects you wish to copy by this method, and that ByteArray's readObject will check the object to see if it implements IExternalizable, otherwise it will just copy its public properties. This is why most of the built in classes will fail to copy.

On the point of copying Graphics from within Display Objects, there are a few methods you could use:

As of FP 10, Graphics has another useful method.

public function copyFrom(sourceGraphics:Graphics):void

(http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html#copyFrom())

So once you've copied your Object, you can then manually copy the graphics over. Just put this in to the copy() method. Just check to see if it extends Sprite or MovieClip and then call copyFrom(). This would be the easiest to write.

And here is another new method.

public function drawGraphicsData(graphicsData:Vector.<IGraphicsData>):void

(http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html#drawGraphicsData())

If you were to store all the commands as raw data (even JSON them, or create internal DTOs), then write the IExternalizable methods to copy the commands over to the new Object and repopulate the Graphics using this method. This would be a pain to write, but would mean you just call the copy() method and you have a copy, Graphics and all, without any custom code in the copy() method. You could also call the graphics methods dynamically based on the commands, so you could get this to work in FP9 if required. This has the added bonus of allowing you to change the commands as that's not currently possible. Once you write to graphics, you're stuck with it.

Answer 3

You can't make an exact copy, but you can easily create a surrogate bitmap. Which works for me in most cases (fills, thumbnails etc.)

See BitmapData's draw() method.

Answer 4

Short answer:

Graphics are not introspectable at runtime. No matter what Kirupa's code is doing, it has no way of knowing what shape you drew, and no way of copying or re-drawing it. (The textfield getting left out might be a bug or by design, I have no idea, but there's no getting around the shape.)

Long answer:

A DisplayObject is not just a chunk of memory, like a bitmap or a string. It's an object, with a great many child properties, many of which are also objects, or functions, or classes, etc. So when you say you want to duplicate one, it's worth asking what precisely that means. Should child objects, like Arrays for example, be copied by reference or duplicated? If any of the objects hold references to other display objects, besides their list of children, how do you know whether to copy the reference or duplicate the target? If some of the original objects were listening for keyboard events or running timers, would the duplicates work without being registered as well? Et cetera, et cetera.

All of which is a long-winded way of saying, in OOP languages (like AS3), there's no universally meaningful way to duplicate objects. Granted, you can recurse through a tree of MovieClips, making new ones and attempting to copy properties from the originals to the duplicates - and that's what Kirupa's code is presumably doing. But for anything except trivial content, as you're finding out, this won't get you what you want. That's why there's no built-in way to do this - because most of the time it wouldn't do what people hoped.

Ultimately, the real solution to this kind of problem is to take a careful look at what needs to be accomplished, and figure a way to do it without duplicating objects. If you need only a visual copy of the original, you might consider drawing the original into a bitmap every frame. Or perhaps the best approach is to build a data structure containing all the information relevant to your object, so that you could duplicate the data and initialize an object based on it. Or perhaps you should be creating a pool of objects initially, and maintaining each, so that when you need duplicates later you have them.

Either way, at the end of the day the problem is architectural, so the solution will need to be as well.