Как добавлять на сцену мувиклипы не из основного класса.
 

Здравствуйте. Интересует следующее:
Например, мне необходимо добавлять на сцену мувики из библиотеки средствами as3(flash cs5.5).
Если это делать из основного класса документа то все понятно-ставим экспорт для экшена в свойствах мувика в библиотеке.Затем в коде пишем к примеру следующее и мувик как и положено появляется:

Но как проделать такую же операцию не из основного класса документа, а из какого либо другого?!(класс состоит в одном пакете с основным классом документа)

Добавлено через 12 минут
Поясню еще. Допустим в основном классе документа я создаю экземпляр некого другого класса состоящего в одном пакете с основным классом документа.В конструкторе этого некого класса я пытаюсь добавить в список отображения мувиклип все тем же аналогичным способом:

Но ничего не происходит. Конструктор выполняется, проверено-trace.Но мувика нет. С основного же класса документа такая махинация работает.

Добавлено через 13 минут
сабж up

Добавлено через 36 минут
ауууу

Передавай в другой класс stage или this из основного класса, затем просто в другом классе делаешь своё this.addChild(b); или stage.addChild(b);

Вот и все... ))

Уловил махинации? Можешь в конструктор YourClassContainer передать stage и добавить обьект на stage.

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

Добавлено через 8 минут
temofony, апать темы запрещено Правилами форума. Здесь Вам никто ничем не обязан; покрикивайте на своих подчиненных, если они у Вас есть.
Теперь Вы это Правило знаете. Напоминаю, что третий плюс означает бан.

спасибо vizgl)

Обоснуй плиз про stage

это не создаёт никаких плюсов. Просто представьте что documentClass это stage и добавляйте всё в него.
Это несёт минусы по части всплытия ивентов мимо документ класса и создаёт некоторые не столь очевидные архитектурные проблемы.

На stage добавляется дисплейный объект-контейнер Документ-класса.
Все остальные объекты должны являться его детьми и управляться им.
Все, что вне Документ-класса, является вражеским контингентом, неуправляемым и непредсказуемым, находящимся "в плеере", но ВНЕ приложения.
Не говоря уже о том, что сама по себе команда из Мейна "стейдж, добавь себе это дитя, и без вопросов" является грубейшим нарушением священной иерархии "дети не приказывают родителям, а только информируют их".
Если всякая второстепенная мелюзга будет изменять по своей прихоти родительские объекты, на приложении можно ставить крест.
Это и есть те "некоторые не столь очевидные архитектурные проблемы", о которых упоминает Aquahawk. Я бы сказал, очевидные и недопустимые.
Просто товарищи начинающие частенько не осознают терминологию, просто не знают как правильно сказать, а как сказать не надо))
В результате и сформировался такой слэнг, "добавить на стейдж", и все это повторяют повсеместно, вплоть до примеров кода(!), где бездумно пишут stage.addChild(...).
Хотят сказать "добавь на сцену", при этом под сценой подразумевая тоже не Scene, а Display List вообще.
При этом и слово "сцена" заменяют словом стейдж, подразумевая некое абстрактное вместилище дисплейных объектов.
Но оно не абстрактное. Стейдж это вовсе не стандартный DisplayObjectContainer, у него очень много своих нюансов и свое конкретное назначение, выходящее за рамки логики приложения.
Приложение не может пользоваться стейджем как своим ребенком в любом смысле. Это Приложение является ребенком Стейджа.
Соблюдайте иерархию, и вопрос потеряет смысл.

Wolsh Мне лень было всё это писать. Абсолютно точно.

На счет стеджа, так глубоко не задумывался, хотя ничего на него не добавляю. Спасибо за разъяснение

Уважаемые, красиво ли делать в ребенке мейна some_class_1 так:
что бы потом обращаться к некоему видимому из мейна класcу main.some_class_2 ?

нет некрасиво. Если ребёнку вообще не нужно знать ссылку на мейн, ну вот прям совсем не нужно, отправляйте событие из себя.

Я пишу Flash IDE компоненты и для создания алертов и прочих попапов я использую стейдж, который выше рута. Туда добавляется несколько слоёв менеджеров для для отображения алертов, попапов, курсоров и прочей нечести. У них там свои события и своя микрофлора. Делаю это потому что все эти вещи всегда, не зависимо от логики конечного приложения, должны быть выше всего контента приложения. Благодаря этому подходу я могу не париться о том, что там напишет другой разработчик. Стейдж такой же инструмент как и прочие публичные вещи в API флеш плеера.

Да-да. То есть, как бы ни хотел товарищ разработчик поместить свой курсор выше всего контента, он все-равно будет проваливаться под ваши алерты и попапы. Бедолага вынужден использовать Ваш курсор? Отличное решение вами же созданных проблем)) А главное — как же неимоверно сложно было научить менеджер добавлять попап наверх списка отображения рута....

Это вы по кофейной гуще нагадали или звёзды подсказывают? Курсоры легко, без проблем, меняются. Зачем кого-то чему-то учить если можно просто добавить поверх всего?

Например? Вы можете создать новый экзепляр Stage? Добавить его ребенком в Список отображения? Изменить высоту/ширину? Написать для него свою логику управления детьми, которых в него добавляете?
Охотно верю. Пусть парится он. Чудесные AS2 компоненты от Adobe всё еще живы в памяти))).
Да потому что костыль. Быстрое, простое и очевидное неправильное решение "лишь бы работало".

Полезность инструмента характеризуется возможностью создания экземпляров его класса или возможностью изменения логики его работы? Это странно и вопросы странные -- вы задаёте вопросы на которые уже известны ответы. Например, я могу добавить в него детей, могу изменить режим отображения fullScreen/normalMode, могу добавить stageVideo для отображения, и прочее можно посмотреть в референсе. Не хотите/не умеете пользоваться, не надо, никто не заставляет. Так уж сложилось, что точкой входа в приложение служит рутовый дисплей обжект, а не стейдж, но это же не значит, что теперь его использования нужно избегать.

Надеюсь, на этом доводы не закончились.

Ага. Это называется "риторические вопросы".
Хм... Я вроде говорил только о том, что в него не надо ничего добавлять. Все что нужно в него уже добавили, никого не спрашивая)) Хотел бы я увидеть приложение, никак не использующее стейдж.

Правильно ли я понимаю, что Вам нет дела до писанины разработчика, использующего Ваши компоненты, ровно до того момента, пока он не напишет в своем коде "stage.addChild()"?

В стейдж добавили то что необходимо для работы приложения и методы субкласса DisplayObjectContainer. Разработчики флеш плеера могли достаточно просто запретить добавление объектов выше рута.
Верно, по большому счёту нет дела. Моя задача указать как пользоваться и что делать нельзя. Вероятность того, что он полезет на стейдж _значительно_ меньше, чем вероятность добавления детей в рут.

Все равно мне кажется это спорный вопрос... Если приложение нуждается в доступе к stage, то нужно его в любом случае передавать. Я встречал много уроков толковых разработчиков где передавали stage в другие классы (Например при использовании box2D...)... Или например, как мне получить свойства stage из другого класса... В этом случае нужно передавать stage в другой класс... А иначе как?

Добавлено через 13 минут
Wolsh, по сути вы предлагаете создать какой-то контейнер и работать полностью с ним? Я правильно понял?

Между прочим тот же самый Box2D прекрасно отображается в любом DisplayObject, и конкретно Stage ему совершенно не нужен.

Выше уже писали о том что несомненно без stage приложение не будет иметь отображения. Но речь идет не о том чтобы отказаться от использования stage, а о том, чтобы добавлять на stage уже готовые контейнера с программой.

Лично я при разработке например игры, всегда свожу к тому, что у меня есть только один главный визуальный объект, который добавлен на stage. Например это класс Game. Который уже в свою очередь содержит контейнера Status, Player, Controller, Map и прочие.

Я всегда могу сделать любые операции с моим визуальным объектом Game. Например добавить сверху рекламу, или какие-то другие элементы. Не затрагивая основной класс игры.

Добавлено через 4 минуты
Забудьте слово root. У вас всегда должен быть главный контейнер приложения. И это не должен быть stage.
Неужто вам так тяжело всю программу просто обернуть еще в один класс?

Если класс сам не является дисплейным, при этом занимается управлением объектами, и ему нужен stage для прослушивания событий — Вам никуда не деться от ссылки.
Еще раз... Моя критика касалась советов использовать стейдж как контейнер для детей Приложения. Я пока еще в здравом уме и ни разу не говорил "навсегда забудьте про стейдж и ни в коем случае к нему не обращайтесь". Тем не менее, раздавать ссылки на стейдж надо только тогда, когда в этом действительно есть архитектурная необходимость, а не наоборот — раздавать ссылки на стейдж чтобы настроить костылей вместо правильной архитектуры.

Wolsh, но увы. Вас не слышат)

Смотря о чем речь)))
Если вообще, то такой контейнер уже есть — рут, он же "экземпляр класса Документа" (к слову в AS3 понятие root вполне кошерное, в отличие от AS2, и не надо его бояться). Он добавляется на стейдж автоматически и в нем то и должно содержаться всё приложение. То есть я, напрмер, помещаю экземпляр Основного класса Приложения (скажем, Game) в этот контейнер (пример причины "зачем так" указал strangedk).
Если же речь о "слоях", как в случае с компонентами, то ДА, я бы делал контейнер для всей этой братии и позволил разработчику на свое усмотрение располагать этот контейнер и заботиться о его "всплывании", если в этом есть необходимость. По-моему, любой разработчик, создающий архитектуру "слоистого" приложения вполне отдает себе отчет, что такое приложение сразу, изначально делится на специальные контейнеры-слои, сразу и навсегда размещаемые в нужной последовательности по глубине. То есть курсоры (сейчас это не так актуально с новыми возможностями "честной" замены курсоров, ну допустим не курсоры а перетаскиваемые драгом объекты) помещаются в контейнер "на самом верху", под ним контейнер для модальных окон, ниже — для подсказок-хинтов и в самом низу — непосредственно интерфейс приложения. Как-то так в общих чертах.