Вопросы по stage
 

От нефига делать (и от желания отточить скил) начал писать казуальную игрушкку типа "Танчики"
Итак, есть базовый класс WarMachine - это шаблон танка, при клике на стейдж внутри этого класса генерится объект типа Boolet, пуля которая меняет коородинаты на EnterFrame, и аттачится на главный стейдж.
Посему вопросы:
1) Щас лиснер на клик аттачится на стейдже (выстрел). Можно ли зааттачить его внутри самого WarMachine? Пробовал через root.stage - не помогло
2) На стейдже лежит мувик booletContainer, в который надо складывать пули. Как к нему добратся их WarMachine?
root.stage.addChild(b) работает, а root.stage.booletContainer.addChild(b) - нет
3) Сделал выстрел по нажатию пробела, тот способ что и с управлением через булевы переменные, где управление стрелками реализовано. Оно конечно работает, но поскольку висит на EnterFrame то пули вылетают пачками и надо очень коротко нажимать. Можно как-то это сделать попроще обрабатывать и назначать как с тем же Mouse Click?

1) В базовом классе WarMachine, создайте статичную переменную и при инициализации главного класс присвойте в эту статичную переменную ссылку на stage, и потом из любого класса сможете обратиться к stage.

Потом в Любом классе пишите

1) да. У каждого display object'a, находящегося на сцене есть stage (код выше решает эту проблему симпатичнее, кстати, рекомендую).
2) Как-то передать WarMachine ссылку на booletContainer (bullet - правильно). Ну или дать возможность её достать =) Думаю передача параметром в конструктор тут - не криво совсем.
3) Ну можно на KEY_DOWN повесить. Можно смотреть, сколько с прошлого выстрела прошло. Как пан пожелает)
PS: танчики - неказуальны. Казуалки на казуальных порталах и флешки на флеш порталах - разные вещи. Чисто терминологическая поправка %)

2) Зависит от того как booletContainer добавляется на stage. Если через addChild, то дайте этому контейнеру name = "booletContainer" и обращайтесь к нему

Если для точения скилла, а не быстро накидать, посмотреть и забыть, то про getChildByName - забыть.

Если контейнер один и добавляется всего раз на сцену, то просто запомните ссылку и обращайтесь через нее, можно даже сделать ее статичной (смотрите пример выше)

-De- - ну ты критикан =)

Сам по себе getChildByName не вреден. Вреден он в конкретно данном случае, но менее вреден, чем вариант со статическим stage.

Чем вреден статический Stage?

избавляет от множества проблем во внутренних классах, если надо вешать лисенеры MouseEvent (как бонус)

Ну и слушайте MouseEvent, когда вы находитесь на stage. Если не находитесь, нечего слушать.

Частая ситуация, делаешь скроллер и нужно отрабатывать stopDrag(); когда срабатывает событие MouseEvent.MOUSE_UP, нужен глобальный MOUSE_UP, а не над объектом

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

П.С. Stage существует всегда, хранить поинтер на постоянно существующий объект признак грамотного программирования, я так считаю...

Гомерично ржал (уж простите). Обратится к статичному поинтеру или постоянно дёргать метод. Выбор очевиден.
Некие события stage нужны независимо от того, какая иерархическая структура результатирующего класса.
Обычно, опыт и серьёзные проекты отметают возражения на этот счёт

RaVeN-Nikma, нельзя, потому что не находящиеся в display list объекты вообще не должны ничего делать. Ссылка на stage у вас будет, подписывайтесь на здоровье, потом отпишитесь точно также.
Однако, если вам наплевать на расход памяти и в вашем коде removeEventListener встречается на порядок реже addEventListener, вы можете пользоваться любым удобным для вас способом.

me2, выбор очевиден, действительно. Для узкомыслящих.

Если удалять листенеры объекта после его ухода со сцены, то никакого дополнительного расхода памяти не будет, этот момент косвенно касается статичного хранения ссылки на stage, и видимо все возвращается к первоначальному: "кому как удобно", и слово нельзя тут не уместно.

Спасибо за дискуссию

Не возвращается, открытые и доступные всем и вся ссылки на stage — потенциальная недоработка.

Все можно когда пишешь код один, но когда пишет группа, то статичные объекты, да ещё которые можно изменить - это зло.

Мда, и как всегда - куча мусора, ничего дельного. Не знание основ работы display list`a, не умение широко мыслить, не знание "не шаблонных" приёмов программирования.

"потому что не находящиеся в display list объекты вообще не должны ничего делать" - (поржал вторично)

Подытожим - использовать static stage дело правельное и нужное. Желательно указать в main.as

Чистить за собой - это первый класс, обсуждать и указывать на использование removeEventListener - это бред, и так понятно.

Думать что lifetime и interactions объекта привязаны к его видимости в displayList - очередной бред. срочно к санитару.

Носится каждый раз по displayList`у с geChildByName() - за это стрелять в голову. (этож надо... name... так кодили на as2 во фреймах)

К сожалению оппоненты использования static stage проявили высшую степень некомпетентности, не подкрепив весомыми аргументами и доказательствами своё мнение. За сим считаться с ними совершенная бессмыслица.

P.s.
Bgg
это всего лишь вопрос профессионализма. сделай getter на static stage, а в setter`е не позволяй менять, если уже синициализировано.

Риторическое отступление:
На что можно изменить public static STAGE:Stage, кроме как на Stage или null, да и зачем его вообще менять, даже работая в команде. Вы же не работаете в кругу врагов, которые так и мечтают из своего класса в main.as в STAGE поставить null, чтобы все сломать )))

Что касается в общем статичных переменных, то тут пожалуй соглашусь.

me2, слишком толсто, маловато огня.

etc, а в что, действительно, плохого в использовании статической ссылки на stage?
У меня статическая ссылка на сцену используется для добавления разных окошек с предупреждениями, которые сами добавляются поверх всего остального, и сами же полностью удаляются при нажатии кнопки подтверждения. Не буду утверждать, что это лучший, или даже один из лучших методов, но он однозначно удобен.
П.с. А во избежание зануления ссылки, можно использовать private static var и назначать ее сеттером, в котором проверять новое значение не валидность

А зачем она? Какой смысл делать stage доступным всем и вся? Надо подписаться события — подпишись после ADDED_TO_STAGE, сохрани локальную ссылку, чтобы потом отписаться, занули и тебя соберет GC. Если это клавиатурный менеджер — передай линк на Stage извне. Меньше связанности, меньше свободного доступа к чему-либо — всё это располагает к неограниченной расширяемости и возможности распиливания проекта на отдельные части, безболезненной замены одной на другую. Это всё та же концепция черного ящика, который замкнут внутри себя и работает внутри себя, не распуская руки туда, куда не нужно. Если ему что-то нужно для работы — это всё должно прийти снаружи. Я уже не говорю про отсутствие конфликтов кода при разработке проекта несколькими людьми, при условии, что они соблюдают концепцию, конечно.

Если завтра придёт очередной джуниор и подпишется в трехстах местах на этот самый статический stage в каком-нибудь вьювере, даже ещё не добавленном на сцену, насоздаёт этих вьюверов «про запас», убирать за ним желания никакого. Лучше он спросит, как сделать правильно, просто уперевшись в отсутствие доступа. И потом будет делать всё правильно.

Статический stage, банально, тащит за собой класс-холдер, а он в свою очередь тащит ещё всякой дребедени за собой.

У Stage есть свойства которые можно изменять. Stage полон событий, на которые можно подписаться и забыть отписаться.

Статичный Stage это лень. Из-за него появляется сильное связывание, и классы становятся привязанными к своему месту. Мелкое обновление архитектуры повлечет за собой перетаскивание статичных ссылок.

А ещё удобнее сделать контроллер окон, который бы ловил всплывающие события от окон и решал закрывать окно или нет.

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

Добавил статичный Stage в main и теперь меняй архитектуру как хочешь, 100 или 1000 классов, ссылка всегда будет одна, и ничего не полетит.

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

У DisplayObject-ов ссылка и так появляется после добавления в display list.

Ваше мнение насчет, того что не DisplayObjects вообще не должны ничего слушать, я прочитал выше

Нет. Мой вариант удобнее этого. Чтобы он ловил события от окон, нужно его еще подписать на эти события. В моем же случае окошко с предупреждением добавляется из любого места через статический метод WarningWindow.showWarning(text:String);
Поэтому, класс в который записывается статическая ссылка нужно хранить в корневой директории проекта, и можно будет менять архитектуру как угодно

Бывают случаи, когда ссылка нужна еще до добавления

Я этого не говорил. Вы меня невнимательно прочитали.

Добавлено через 30 секунд
Пример, пожалуйста.

Верно, эти слова расценил так

Пример: контроллер клавиатуры, который сам по себе не является дисплей объектом и, соответственно, вообще не добавляется на сцену. Но подписать слушатель к сцене из него нужно. Соответственно, нужно либо передавать ему ссылку в конструкторе, либо использовать статическую (ну или передавать через сеттер, не важно)
Так же, используя статическую ссылку можно отписать сцену от какого либо события даже в объекте, который уже удален из всех контейнеров. Это быдлокодерство, не буду отрицать, но у меня есть код, который большую часть времени отписыват сцену от событий нормально, но время от времени почему-то выдает null reference. Решил статической ссылкой, ибо перелопачивать всю эту гору кода в лом

Я не это имел ввиду. Я имел ввиду, что DisplayObject, если он отсутствует на сцене, потенциально или только создан и ещё только будет инициализироваться, либо уже удалён и отписан от всего. События от Stage в эти моменты ему не нужны совершенно.
Про клавиатурные менеджеры я уже описывал выше, ссылка на Stage передаётся в конструкторе.

goodguy, с контроллером клавиатуры понятно, только единственный адекватный вариант — передать ему ссылку для работы снаружи. Что касается отписки, то до REMOVED_FROM_STAGE можно держать ссылку у себя любимого, затем при возникновении события отписаться и удалить ссылку. Опять же, я об этом писал пару постов назад.

И да, как уже говорил Bgg, это всё лень и подтверждения этому:

И тем не менее. Серьезных аргументов против использования статической ссылки на сцену я не вижу.
Похоже это просто дело личных предпочтений

Это не предпочтения, это личный многолетний опыт. Недостаточно аргументов? Я их привёл достаточно, на мой взгляд. Усугубляет ещё то, что мои посты ещё и невнимательно читают. Да и вообще, почему я ещё должен кому-то что-то доказывать?
Я поделился опытом, если вы хотите сами наступать на грабли — пожалуйста.

Согласен с goodguy

Не нужно создавать шаблоны, как можно и как нельзя делать

etc, зачем доказывать? Я просто спросил, чем это чревато. Если это действительно плохо, то я откажусь от такого способа. Но просто пока не вижу ничего плохого в этом... Вижу только плюсы. Меньше кода приходится писать. Не нужно в каждом объекте добавлять прослушку Event.ADDED_TO_STAGE

goodguy, мне уже не хочется повторяться, прочитайте ещё раз внимательно двадцатый пост.

Высокая связанность классов — вот главный недостаток этой вашей статики. Помноженное на ламерство, даёт ещё и гигантские утечки памяти в купе с полным отсутствием хоть какой-то логической структуры кода.
Я уже много всякого *****кода ковырял, поверьте.


И вообще, я вот ищу флешеров толковых на хорошую зарплату, тех, кому можно доверить свой код и не переживать о том, что через полгода он может превратиться в кровавое месиво. А некого! Флешеров больше, а уровень совсем хреновый. Печаль.

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

Вам просто видимо нужны флешеры, которые мыслят как Вы. Самый верный способ тут, видимо только клонирование

А я пожалуй соглашусь с etc.
Никогда не пользовался статической ссылкой на Stage, в проектах любой сложности. И как-то не было надобности. Яркая трабла уже была названа: если в проекте есть что-то общедоступное, у всех разработчиков так и руки чешутся использовать эту ссылку. После чего вернуть нормальную структуру бывает сложновато. Например есть в проекте четкая иерархия GUI, где есть менеджеры по фейсу и тут кто-то начинает добавлять себя на Stage не спросив никого! Не приятно. Так еще и не все сознаются ;)

дык это и есть связанность :)

=)))) А зачем куда-то еще ее переносить, stage всегда один, почему бы ему не быть в корне. Попробуйте ради эксперимента, и потом говорите что это не удобно или плохо

П.С. пора отписаться от тема, работать невозможно

Ну тогда радуйтесь жизни))

Короче спор бессмысленный. Если, как говорит etc, код будут делать несколько человек, то лучше не использовать статической ссылки, чисто ради того, чтобы код был понятен остальным. Но если сам и только для себя, ничего плохого в этом нет. Отписываться от слушателей и зануляться саму ссылку на stage это никоим боком не мешает
нет там никакой связанности.