Document class создается не первым
 

Простая флешка. На сцене находится только один муви клип. Он при создании должен подписаться на событие главного класса. Так вот у клипа конструктор вызывается перед конструктором Document class'a, что приводит к рантайм ошибке.

На сколько это нормально? И что делать в таких ситуациях?

1. подписывать из Документ-класса (криво, но идея использования объектов на сцене + документ класса сама по себе кривая...)
2. слушать ADDED_TO_STAGE у стейджа, если таргет события == Документ-класс - подисываться... (ну тоже красивым решением не назовешь...)

Чем обосновывается кривизна идеи?

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

Так в этом то и вопрос: почему документ класс создается не первым :)

Объясню ситуацию, чтобы было нагляднее.
Есть эмулятор телефона. На нем есть экран и клавиатура. Экран при создании должен подписаться на события клавиатуры. К клавиатуре он пытается достучаться через документ класс (он ведь главный, и содержит этот клип). Но почему-то экран создается быстрее самого документ класса, что и приводит к ошибке.

Проблему то решил созданием объектов в конструкторе документ класса. но все равно этот вопрос меня интересует. Как-то нелогично получается.

Пусть стучится до класса документа по ADDED или ADDED_TO_STAGE.
Логичнее было бы если из конструктора класса документа не были бы доступны мувики созданные в среде?

Ну... а мне почем знать почему он раньше создается? =) Т.е. почему - я примерно могу себе представить, а вот зачем так сделано - не знаю =) Мало ли фич, которыми лучше не пользоваться не смотря на то, что технически их сделать никакого труда не составит =)
badun:
не, логичнее было бы, если бы мувики созданные в среде создавались последовательно после того, как будет создан "главный" мувик - он же документ класс =) они ж по идее его "дети" как ж это они вперед "батька"? =)

Если бы они создавались после главного мувика, они не были бы доступны в его конструкторе. Как в таком случае достучаться до них, ловить каждого на стадии bubbling события ADDED?

Чесно - я вообще за рантайм ошибку при создании чего бы то ни было "не проконсультировавшись" с Документ классом с примерно таким текстом: "Alas! 3999(a): Ye shall not reap yet thy sow!" =) Но, если это неизбежно - ну, да... слушать когда добавили... а что?
*Благо наш QА не подозревает о существовании дебаг плеера... :rolleyes: *

по-моему все-таки проще чтобы каждый ребенок слушал когда его добавили ))

Меня полностью устраиваетc ADDED_TO_STAGE.
Такая подход мне кажется вполне логичным
Я, наоборот, всех заставил ставить дебаг версию, чтобы не слышать:
"А ааа опять твоя флешка не работает"
-)))

Document class - ничего кривого не вижу. А вот "объект на сцене" - вот эт уже костыли...
У вас есть library для assetов классов, у вас есть Export to SWC опять же. Зачем вам stage?!

Хм... Ну на том же примере телефона.

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

это хранить графику в отдельной подгружаемой либе, а то что вы пытаетесь сделать, называется каша... "красивенько расставлять" и вообще собирать интерфейсы надо используя XML, а если не хочется (или не умеете), то пишите на AS1/AS2...

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

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

Почему это плохой метод, если это технология флеша?

Да и еще, тему то я создал, чтобы разобраться, понять, а не для того, чтобы тут писали субъективные названия того, что происходит, и учили на каком AS писать. Спасибо, сами решим на чем писать.

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

NewFolder >> расставьте всю графику на сцене и дайте разработчику. Он создаст в либе классы, в Док-т классе расставит их как надо.

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

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

Потому, что ими удобнее так управлять :)
Я думаю, это самый лучший аргумент.