Разница между кодом в кадрах и в пакетах/классах
 

Здравствуйте ув. форумчане.

Интересуют по сути 2 вопроса связанные между собой:

1) Какая разница, писать код по нажатию F9 (т.е. в кадрах), либо создавать отдельно *.fla и *.as файлы, связывая их.

2) В чем разница между instance name либо экспорт для as3.0 (когда создаю символ)

Убедительная просьба подробнее и без воды...

Заранее спасибо.

1. Разница огромная:
Символ - динамический класс наследованный от базовых Sprite или MovieClip. таймлайн в символах или главный таймлайн, это тоже - динамические классы MovieClip. Код в кадрах - это методы динамического класса. Код в кадрах - сильнее запутывает и менее структурирован, чем код написанный в классах.

2.instance name задаёт вашему уже созданному экземпляру класса строковой параметр name. Экземпляр класса - это объект определённого класса уже имеющегося на сцене (или в памяти), как например текстовое поле на сцене являющееся экземпляром класса TextField.
Задавая имя для экспорта, вы фактический делаете ваш клип (или по другому созданный вами класс) доступным для вашего кода и сможете создавать экземпляры этого класса: new MyHuman() в любом месте программы.

Ваши вопросы прямо касаются ООП парадигмы в AS3. Это слишком большая тема, что-бы уместить её в одном сообщений да ещё "подробнее и без воды". Подробнее будет в какой нибудь книжке, посвящённой ООП во флеш. Например Колин Мук достаточно ясно разъясняет все нюансы.

Не совсем точно. Главным образом instance name определяет имя переменной, которая является ссылкой на данный объект.

Zebestov,
Как всё сложно в этом ide :)

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

Никогда объекты, ни похожие, ни не очень похожие, не объединялись в классы.

Хм. Тогда так:
Для объектов с похожими методами и свойствами, можно создать классы.

Используйте FlashDevelop для кода, а Flash CS - для графики и последующего экспорта её в swc/swf.

Я вот сам с легкостью даю такие "советы", потому что учился писать код в классах еще на AS2 — перед этим года два используя его же в кадрах, потом в единственном кадре + классы, и наконец, только классы в FD. Я даже представить не могу, как бы я начинал писать код в классах на AS3 в FD с нулевого уровня владения языком и знания внутренних процессов технологии. Скорее всего — никак.

Себя я как пример не могу привести)) но я вот как раз и начал с классов и FD. Правда обратная сторона этому тоже есть. В погоне за результаты в классах, я узнал о паттернах раньше чем понял, что такое parent и root на деле. Дико может казаться тем, кто сначала учился квадратики рисовать и циклы. Но это только по тому, что вы так не учились!) я на самом деле, отвечая в простых темах, многое делаю впервые и в большей части для того, чтобы мне на ошибки указывали) Страшного на самом деле не чего нет, даже наоборот. Мне кажется что если начинать не с классов и с разу не с изучения гениальных работ, то можно долго быть не в теме.

Я сразу учился писать в FD с нулевого уровня 1.5 года назад.
Проблем не испытывал и не испытываю.

На деле я даже ещё не одной кнопки не сделал... Сделать я конечно могу, но не сделал)))
Не успел написать, чтобы к предыдущему посту добавилось))

Как по мне, FD даёт более полное понимание структуры проекта и её важности. Дерево классов - наглядно. В отличие от кода в кадрах.

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

Кнопка это слишком сложно для человека, обработанного размышлениями о паттернах. Начните с чего попроще. Идеальное задание "для новичка" это чекбокс. В нем, с одной стороны, очень мало мяса и он целиком помещается в сознании. С другой стороны, в нем есть почти все кости AS3 — Событийная Модель, структура Списка Отображения, программное рисование, и с парадигмами ООП есть где развернуться, если поставить себе задачу сделать действительно универсальный, реюзабельный чекбокс. Потом уже можно к кнопкам переходить, у них как раз с последним очень все запущенно. Там самое сложное это найти где поставить точку, то есть осознать, что абсолютно универсальный класс кнопки написать невозможно и найти оптимальный вариант между комбайном и серпом.
Каких классов и свойств? Даже если не подсвечиваются методы и свойства Ваших собственных классов, то автокомплит то у них все равно есть, как можно написать неправильно? А уж у "родных" адобовских классов подсвечивается всё. Разве что в списке кейвордов по-умолчанию многого не хватает.. Ну так дописать надо))

Эээ... Как чекбокс может быть проще кнопки если это и есть кнопка? Точнее это ToggleButton выглядящий как чекбокс. ToggleButton, в свою очередь, кнопка с дополнительным свойством selected и дополнительными состояниями selectedOver и selectedDown.
P.S. Чтобы познать рекурсию надо познать рекурсию :)

Так то оно так, в этом есть педагогический фокус. Чекбокс в 90% случаев не содержит никаких эффектов и анимаций переходов — он слишком мал, чтобы это имело смысл. Автоматически ученик об этом и не задумывается, концентрируясь на состояниях и на тру ООП. В случае с кнопкой же многообразие возможных визуальных реакций сбивает с толку и засоряет мозг. Чекбокс можно делать по нарастающей, от совсем простого "рамочка и +-квадратик", накручивая состояния, возможность добавлять иконки извне или устанавливать цвета для внутреннего рисования, работать с лейблом. Чекбокс проще умещается в мозгу. У кнопки больше разнообразие элементов, требующих внимания. У нее может быть иконка, может не быть иконки, может быть текст, может не быть текста, может быть и то и другое или не быть ничего. И меняться в разных состояниях. И по-разному может быть устроена реакция на ресайз кнопки. Наконец, у кнопок в 10 раз больше специфических вариантов поведения для разных целей. А чекбокс это просто ToggleButton, и то без излишеств.

Добавлено через 14 минут
Akopalipsis, я понятия не имею, с чем работают в реальном мире)) Я никогда не делал сам чекбокс как "просто чекбокс", у меня он всегда является частью библиотеки GUI. Если честно, мне даже в голову никогда не приходило делать чекбокс из битмапов. Для игр это, наверное, самое то; однако интерфейс для игр всегда уникален/индивидуален, и нередко хитро анимирован, здесь это ни к чему. Вам надо определиться только с подходом: будут ли состояния добавляться извне как DO или рисоваться внутри. Выберите что-то одно, или придумайте как иметь оба варианта)) Однако в случае с библиотекой контролов визуальные элементы чекбокса [скорее всего] будут экземплярами других библиотечных классов - лейбла, панельки, иконки. Как я уже говорил, в такой на вид маленькой штучке есть куда развернуться.

По поводу растр/вектор можно сделать универсально, если для компонентов назначить инициализацию с назначением отображения.
Тут кто как привык делать.

Wolsh Мне до утильсов ещё далеко, поэтому я попробую сделать просто как отдельный компонент ( только сначала разберусь с программным рисованием деревьев, а это как я понял на долго ) и как сделаю просто покажу Вам в этой теме как оффтоп. Мне очень важно, именно в педагогических целях, чтобы мне сказали - так ли я делаю или нет. И буду надеяться, что Вы скажите, что там не так...
А по поводу растра я спросил не просто так, но тут об этом не буду, а чуть попозже просто новую тему создам и спрошу именно по нему.

Добавлено через 13 минут
я немного подумал как делать и первое, что пришло на ум - Фабрика! Но это только из-за универсальности, чтобы, если надо квадратный - то квадратный, если горизонтальный, то его. Сначала думал модель пристроить, но ей места ненашлось)

Wolsh, видимо у нас сильно разное видение архитектуры UI фреймворков.

Наверное :) А что, это ненормально?
Я никогда по-настоящему не думал о фреймворке; но, может быть, я лукавлю и то, о чем я думал, называется фреймворк)) А что касается "архитектуры", то ее виденье у меня по нескольку раз за вечер могло меняться — это ты уже собаку съел на теме, а я ленивый и программирование для меня всего лишь хобби, и конечный продукт меня волнует гораздо меньше, чем мыслительный процесс. Проще говоря, "видение архитектуры UI фреймворков" у меня еще в стадии становления.
Конкретный пример разницы приведешь? Чекбокс должен обязательно наследоваться от кнопки, или о чем ты?)))

Кнопка, на самом деле, используется во многих компонентах, как основа или как составная часть. ToggleButton, CheckBox, RadioButton все они наследники кнопки. Они включают весь функционал кнопки и дополняют его специфичными для себя свойствами и состояниями, делать их отдельно смысла нет, это дублирование кода. Слайдеры, скроллбары состоят только из кнопок, все эти ползунки и треки в них это кнопки. Все, что ты расписал в качестве сложности кнопки, также применимо и для чекбокса. Если отделить внешний вид (скин, со всеми его анимациями и визуальными реакциями) от функционала, то кнопка получается очень простым компонентом.

Да, только.. еще раз.. там речь то шла об идеальном задании для новичка, а не об архитектуре фреймворка.
Чекбокс это рамочка и квадратик. На первом уроке ничего больше не надо знать. Графическая часть минимальна. Состояний всего два — checked=true/false. Лейбл вообще где-то за горизонтом в будущем. Кода 20 строк. Но в этом коде все базовые кости AS3. И мозг абсолютно разгружен от красивых перемигиваний и думает о простых и чистых вещах — как сделать программный интерфейс чекбокса удобным для использования в любом проекте. Не в графическом смысле (а новички всегда первым делом кидаются на графику, как лев на мышь). Не в смысле разнообразия возможностей и состояний. Не о собственной крутизне чекбокса, а о его отношениях с окружающим миром. Чтобы он не пытался дернуть метод в Мейне, добавить себя на сцену и т.д. и т.п. Ты, видимо, давно с новичками не общался ;) И прелесть в том, что дальше ты можешь варьировать сложность задания, наращивая уже мясо на эти кости. Но тут уже я начну повторяться.
А про буттоны и их последышей все как у меня, кроме чекбокса)) Ну не делал я чекбоксы с шестью состояниями. Не дорос. Только checked, unchecked и disabled. Возможно, в следующем витке усыновлю его в буттоны. Спасибо)

Но в таких условиях и кнопка просто квадратик :) Ну, не суть.

Кнопка, которая "просто квадратик", должна всего лишь посылать "ой, меня нажали".
Чекбокс должен хранить флаг состояния и обеспечить к нему доступ (раскрывается тема модификаторов доступа и геттеров). Кнопке не нужен перевод в другое состояние извне (кроме дизаблед, но это еще рано). Чекбоксу нужен обязательно (раскрывается тема сеттеров и их отличия от просто паблик переменных). Все это конечно, имело бы место в тоггледБуттон. Но чем объяснять новичку за тогглед и ждать, что он не будет путаться в мыслях с другими типами кнопок, не проще взять то привычное и конкретное, обособленное воплощение, что называется Чекбокс? )))) Можно, конечно, и про танки объяснять на примере бронированного автомобиля. Но не проще взять в пример танк? Я к тому, что тоггледБуттон гораздо ближе к чекбоксу, чем к буттону. "Буттоном" тогглед является лишь графически. И я бы еще подумал, кого от кого наследовать :)

Базовым элементом GUI все-таки логичнее считать "окно" - это область, через которую осуществляется ввод/вывод, т.е. взаимодействие программы с пользователем. Навеяно Windows API :).
Ибо там все суть окна, в т.ч. и кнопка :).