I have to agree with Alex. I've built plenty of Flex apps, very large to very small, and I can't remember thinking "gee I wish I could clone UIComponents". I'm having trouble coming up with a reason I'd want to do this that I can't cover with a well-built component that binds to data for it's state - instantiate a new copy, bind to a copy of the data, and off you go. It strikes me as a feature that would encourage misuse and poor architectural decisions.
Of course I don't know everything :) Do you have a specific example or sample project to illustrate your idea? On Mon, Jan 23, 2012 at 3:00 AM, saurabh jain <jainsaurab...@gmail.com>wrote: > Agreed that there can be ways of implementation which can reduce the need > for cloning a display object, but this can only be reduced not eliminated. > > Also this is not restricted to games. An application for *e.g.* A > Whiteboard application would greatly need this for a copy paste > functionality. > > Regards, > Saurabh > > On Mon, Jan 23, 2012 at 1:22 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > > > On 1/22/12 11:47 PM, "Tink" <f...@tink.ws> wrote: > > > > > TBH this isnt an issue for me when building RIAs (maybe for games), but > > if I > > > remember correctly, and if nothing has changed, this is a player issue > > in that > > > you can't clone a DisplayObject. > > That prevents using a simple bytearray copy to clone, but we could > > implement > > a clone API across all UIComponents. I think you your need for one is > > greatly reduced if you are using MV or MVC. > > > > -- > > Alex Harui > > Flex SDK Team > > Adobe Systems, Inc. > > http://blogs.adobe.com/aharui > > > > >
