Компоненты: готовые и "самодельные"

Настройка скинов

А что, если мы хотим изменить не только цвет, но и сам внешний вид скинов?

Для этого нужно изменить содержимое символа, группирующего элементы скинов. Например, если вы хотите изменить вид галочки у комбо-бокса во вжатом состоянии, вам нужно повлиять на содержимое символа fsb_downArrow_press, который лежит в папке Flash UI Components / Component Skins / FScrollBar skins.

Это можно сделать двумя способами.

• Во-первых, аккуратно подправить сами элементы скинов. Метод практически без побочных эффектов.
• Во-вторых, "выбросить" старые элементы скинов и просто нарисовать в этом символе все, что вам нравится. Например, для fsb_downArrow_press это пройдет совершенно безболезненно (потому что элементы из fsb_downArrow не размещаются программно). Но обратите внимание, если ваши новые элементы будут иметь не такие имена, как старые, то цветами этих новых элементов больше нельзя будет управлять с помощью свойств скинов. Из этой ситуации есть два выхода: либо назвать их также, либо переписать вызовы registerSkinElement в первом кадре слоя README группирующего символа (например, fsb_downArrow_press ).

Возможные проблемы при создании собственных скинов

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

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

Поддержка нескольких скинов

Представьте, что вы хотите написать библиотеку скинов для стандартных компонентов и использовать ее во многих флэш-роликах. Что можно сделать, чтобы не нужно было поддерживать каждый флэш-ролик отдельно? Очевидно, скины нужно держать где-то отдельно от компонентов и иметь способ их подменять. Определим сначала, что именно мы будем подменять (группирующие символы или непосредственно элементы скинов). Второе является более дальновидным решением, ибо:

• загружать потребуется меньшее количество элементов;
• обеспечивается большая гибкость (можно в разных скинах делать разную разбивку на элементы, если это нужно).

Хорошо, а с помощью какого механизма мы будем подменять скины во флэш-роликах? Во Flash MX имеется два механизма, позволяющих сделать это во время исполнения ( runtime sharing и loadMovie, см. лекции 13 и 14 соответственно) и один - во время компиляции ( author time sharing, см. также лекцию 13). Сейчас мы поясним в двух словах, что означает название каждого из механизмов, а подробные разъяснения отложим до соответствующих лекций. Итак, при runtime sharing клип подгружается во время выполнения, при этом путь, откуда берется этот клип, задается в процессе редактирования ролика. Написания программного кода этот способ не требует. Напротив, loadMovie обеспечивает программную загрузку клипа во время выполнения. Наконец, author time sharing (название не является общепринятым) подгружает клип из другого *.fla-файла во время компиляции.

В нашем случае мы будем рассматривать лишь runtime-sharing и author time sharing. Что касается loadMovie, то этим методом, скорее всего, воспользоваться не удастся, потому что структура стандартных компонентов Flash MX этого не предусматривает. Теоретически, конечно, можно установить всем нарисованным элементам компонента режим полной прозрачности, а затем при помощи attachMovie загрузить внутрь группирующего символа нужные элементы (ролик с которыми был, в свою очередь, подгружен во время выполнения при помощи loadMovie ). Практически же это сопряжено со множеством неудобств, вызванных с тем, что компонент ничего не знает про новые элементы, а желает работать со старыми (мы ведь считаем, что вы модифицируете готовый компонент, а не пишете свой). Поэтому далее мы не будем обсуждать использование loadMovie для нашей цели. А вот варианты с author time sharing и runtime sharing мы сейчас рассмотрим подробнее.

• Runtime sharing.

  Для каждого группирующего символа настроим runtime sharing из *.swf-файла с группирующими символами. Группирующий символ вместе со всеми элементами скинов будет подменяться флэш-плеером во время выполнения. Прочтите также лекцию 13, чтобы узнать, как это делается, а также получить представление о возможных проблемах с runtime sharing.

• Author time sharing.

  Для каждого группирующего символа настроим author time sharing из *.fla-файла, в котором хранятся группирующие символы (см. лекцию 13). Тогда при каждой перекомпиляции содержимое группирующего символа будет заменяться на нужное (вместе со всеми необходимыми элементами).

В последнем случае вас может поджидать одна неприятность. Допустим, что вы хотите использовать несколько разных скинов не со стандартными компонентами Flash MX, а со своей библиотекой компонентов. В этом случае полезно настроить author time sharing компонентов из своей библиотеки целиком, чтобы компоненты всякий раз обновлялись у разработчиков при внесении в них изменений (см. лекцию 13). К сожалению, когда вы добавите "второй уровень" author time sharing (для подгрузки правильных скинов), Flash MX перестанет нормально компилировать ваши флэш-ролики, а будет "вываливаться" каждый раз с ошибкой "Pure virtual function call". Если вам зачем-то очень нужно использовать именно такой способ работы, то из этой ситуации есть хакерский выход: нужно отключить author time sharing либо для всего компонента, либо для группирующего символа во флэш-ролике, после чего скомпилировать его, затем можно будет опять включить author time sharing. Но, в целом, мы не рекомендуем такой способ работы (использование "двухровневого" author time sharing ). Если же группирующий символ обновляется при помощи runtime sharing, то вышеописанной проблемы не возникнет (хотя возникнет ряд других - но вполне решаемых - проблем; см. лекцию 13).

Так что если вы на основе встроенных компонентов Flash MX пишете свою библиотеку, которой будет пользоваться несколько разработчиков (и в которую вы, скорее всего, захотите время от времени вносить исправления), рекомендуем обновлять группирующий символ при помощи runtime sharing.