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

[temofony]

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

var b:Bullet;
b=new Bullet();
b.x=getChildByName("ship").x;
b.y=getChildByName("ship").y;
addChild(b);

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

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

var b:Bullet;
b=new Bullet();
b.x=getChildByName("ship").x;
b.y=getChildByName("ship").y;
addChild(b);

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

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

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

[garymar]

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

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

[vizgl]

public function Main()
{
    var container: YourClassContainer = new YourClassContainer();  // должен наследоваться от Sprite или MovieClip
    addChild(container);
}

public function YourClassContainer()   // конструктор
{
    var b:Bullet;
    b=new Bullet();
    b.x=getChildByName("ship").x;
    b.y=getChildByName("ship").y;
 
    addChild(b);
}

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

[Wolsh]

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

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

[temofony]

спасибо vizgl)

[garymar]

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

[Aquahawk]

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

[Wolsh]

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

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

[Aquahawk]

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

[vizgl]

Сообщение от Wolsh

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

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