![]() |
Как добавлять на сцену мувиклипы не из основного класса.
Здравствуйте. Интересует следующее:
Например, мне необходимо добавлять на сцену мувики из библиотеки средствами as3(flash cs5.5). Если это делать из основного класса документа то все понятно-ставим экспорт для экшена в свойствах мувика в библиотеке.Затем в коде пишем к примеру следующее и мувик как и положено появляется: Код AS3:
Добавлено через 12 минут Поясню еще. Допустим в основном классе документа я создаю экземпляр некого другого класса состоящего в одном пакете с основным классом документа.В конструкторе этого некого класса я пытаюсь добавить в список отображения мувиклип все тем же аналогичным способом: Код AS3:
Добавлено через 13 минут сабж up Добавлено через 36 минут ауууу |
Передавай в другой класс stage или this из основного класса, затем просто в другом классе делаешь своё this.addChild(b); или stage.addChild(b);
Вот и все... )) |
Код AS3:
Код AS3:
|
Никогда не добавляйте объекты на stage.
Никогда не советуйте никому добавлять объекты на stage. Всегда отучайте других добавлять объекты на stage. Никогда никому не передавайте ссылку на stage, если этого можно избежать. Добавлено через 8 минут temofony, апать темы запрещено Правилами форума. Здесь Вам никто ничем не обязан; покрикивайте на своих подчиненных, если они у Вас есть. Теперь Вы это Правило знаете. Напоминаю, что третий плюс означает бан. |
спасибо vizgl)
|
Обоснуй плиз про stage
|
это не создаёт никаких плюсов. Просто представьте что documentClass это stage и добавляйте всё в него.
Это несёт минусы по части всплытия ивентов мимо документ класса и создаёт некоторые не столь очевидные архитектурные проблемы. |
Цитата:
Все остальные объекты должны являться его детьми и управляться им. Все, что вне Документ-класса, является вражеским контингентом, неуправляемым и непредсказуемым, находящимся "в плеере", но ВНЕ приложения. Не говоря уже о том, что сама по себе команда из Мейна "стейдж, добавь себе это дитя, и без вопросов" является грубейшим нарушением священной иерархии "дети не приказывают родителям, а только информируют их". Если всякая второстепенная мелюзга будет изменять по своей прихоти родительские объекты, на приложении можно ставить крест. Это и есть те "некоторые не столь очевидные архитектурные проблемы", о которых упоминает Aquahawk. Я бы сказал, очевидные и недопустимые. Просто товарищи начинающие частенько не осознают терминологию, просто не знают как правильно сказать, а как сказать не надо)) В результате и сформировался такой слэнг, "добавить на стейдж", и все это повторяют повсеместно, вплоть до примеров кода(!), где бездумно пишут stage.addChild(...). Хотят сказать "добавь на сцену", при этом под сценой подразумевая тоже не Scene, а Display List вообще. При этом и слово "сцена" заменяют словом стейдж, подразумевая некое абстрактное вместилище дисплейных объектов. Но оно не абстрактное. Стейдж это вовсе не стандартный DisplayObjectContainer, у него очень много своих нюансов и свое конкретное назначение, выходящее за рамки логики приложения. Приложение не может пользоваться стейджем как своим ребенком в любом смысле. Это Приложение является ребенком Стейджа. Соблюдайте иерархию, и вопрос потеряет смысл. |
Wolsh Мне лень было всё это писать. Абсолютно точно.
|
Цитата:
|
| Часовой пояс GMT +4, время: 23:14. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.