как сделать копию мувиклипа
 

Здравствуйте!

Я загружаю swf-ки и засовываю их в массив, этот массив играет роль библиотеки мувиков. То есть мне нужно произвольное количество раз копировать мувик из этого самого массива.
А передачи значения во флеше на сколько я знаю нет... Как выйти из такого положения?

Заранее спасибо!

окакой передаче данных вы говорите?
а насчет копирования есть такой метод getDefenitionByName

ну передача в функцию по ссылке\значению, имелось ввиду то, что во flash нет передачи по значению, а есть только по ссылке

чтото я плохо понял про getDefenitionByName и то, как он может мне пригодится... я ведь говорю о копировании мувиков (просто мувиков без кода внутри)

реализуйте свой метод копирования

тогда как его реализовать, можно пример пожалуйсто?
сам я не догадаюсь просто, как можно скопировать мувик...

если каждой свфке задать свой уникальный класс, то

Тогда уж легче задать в этой swf-ке произвольное кол-во классов, и получать их экземпляры с помощью
Добавлено через 12 минут
Да, кстати, yzhastik, если вам нужно много раз получить один и тот же мувик, то вам этот метод как раз подойдёт.

Здесь loader – это экземпляр Loader, которым вы грузили swf-библиотеку. Также, если вы знаете базовый класс, то экземпляр лучше типизировать. Пусть, например, мы знаем, что мы храним в либе мувики либо спрайты (т.е. наследники DisplayObject). Тогда лучше будет написать

Тогда в случае, если объявление такого класса содержится в библиотеке, и он действительно имеет в качестве базового класса класс DisplayObject, то в переменной inst у вас окажется нужный вам экземпляр. В противном случае inst будет равна null.

Метод же clone() раелизовывать нужно тогда, когда требуется скопировать объект вместе с его состоянием, то есть учитывая изменения, произошедшие в нём с момента создания.

а можно ли проделать все тоже самое только с учетом того, что я сначала загружаю мувики, затем засовываю их в массив, а уже потом (из массива) мне нужно скопировать экземпляры этих мувиков?

метод не подходит только изза того, что мувики я загружаю последовательно, и в лоадере останется инфа только о последнем...

конечно можно, вы можете в массив запихивать экземпляры класса Class, хотя я вот точно не знаю, будут ли они доступны после того как вы сделаете лоадеру unload

вряд ли...
хотя кто его знает)

а вообще, зачем выгружать библиотеку, если её планируется использовать? :)

хмм... неужели никто с подобным не сталкивался? когда нужно разместить произвольное количество независимых копий одной и той же swf-ки?

вам уже ответили несколько вариантов.
чем вас не устраивает этот?
к тому же вам никто не мешает для каждой загружаемой свфки использовать свой собственный лоадер..

Ну а кто вам мешает грузить их параллельно? Или это дело принципа? :)

Во-вторых, несколькими постами выше я вам показал метод, использующий всего лишь одну swf-библиотеку с набором классов. В этом случае нужен всего лишь один загрузчик.

И, наконец, никто не мешает вам объединить эти два метода: грузить несколько библиотек, в каждой из которых содержится набор классов (наимер, разные темы графического оформления, наборы персонажей, ...)

я этот метод пытался уже применить но с первого раза он почему то у меня не пошел... сейчас еще раз попробовал... и о чудо все получилось! Спасибо большое, это как то что мне было нужно!

unload не влияет на содержимое applicationDomain. Как говорится, слово класс не воробей: засветился - не вырубишь и unload'ом.

Оп, а вот это интересно) Т.е., если после loader.unload() я обращусь к loader.contentLoaderInfo.applicationDomain.getDefinition(...), то получу то же, что и до unload-а?
А что будет в случае загрузки нового содержимого в тот же лоадер? И как тогда избавиться от уже не используемых классов?

Definitions [of application domain]. The definition can be that of a class, a namespace, or a function.

Небольшие исследования показали, что при живой ссылке на application domain не происходит выгрузка definitions, даже если вы сделали
loader.unload() и убили сам loader. Но стоит зарезать последнюю ссылку на аппдомен, то он тут же будет съеден GC при очередной чистке. А без ссылки на аппдомен никак не получить definition, т.е. это бессмыслено. Если грузить в ApplicationDomain.currentDomain, то definitions, по понятным причинам, живут до кончины приложения.

Понятно, спасибо за полезную информацию)

Это еще не все. Я буду Капитаном Очевидность, но подтвеж(у(ду?)хехе), что ничего нового нельзя загрузить в существующий Application domain, помимо того, что там уже есть. Flash Player просто не даст Вам это сделать. Я про конфликтующие имена классов, неймспейсов, функций... короче, definitions, которые уже существуют там.

Это, ктсати, совсем не очевидно. И похоже, что даже не так. Если, конечно, я вас правильно понял :)
Во вложении совсем немного модифицированный для наглядности пример из адобовского хелпа, демонстрирующий обратное.

да, у меня с этим словом тоже всегда проблемы =)

Чорд. Ну не купил (и не крякнул... пока.. тока тссс...!) я себе CS4. Конвертер посоветуйте =)
А код оформлен супер!

И правильно. Ничего в нём такого нет, только тормозов больше :)
Если флеш не врёт, что может сохранять в формате CS3, то это должно заработать)

Code review:
Зачем Вам каждый раз создавать инстансы типа ClassLoader?

По переопределению. Я же сказал, что конфликтный класс обламывается, и пролетает как фанера над Парижем.
В Вашем коде _тожесамое_ =)

З.Ы. Экстендз Sprite - это банально =)
Даёшь реальный дефинишн!!

Эт не я их создаю. Это господа из Abobe, так что все жалобы к ним :)
А, ну значит, я всё же неправльно понял) Я просто подумал, речь шла о том, что такие действия приведут к рантайм-ошибке.

Зато дёшево, сердито и реалистично :)

Это уже не в моде?

http://martinfowler.com/articles/injection.html

Добавлено через 21 минуту
up по-моему =)
есть мысль, что пока существует объект, созданный из дефинишина аппдомена, и этот объект имеет ссылку на loaderInfo.applicationDomain, то аппдомен здравствует и существует благодаря такому объекту.