Описание проектирования конфигурации элемента пакета HiAsm дано на примере использования встроенного менеджера (меню Сервис->Редактор элемента) ECreator.

   Конфигурация элемента состоит из пяти основных секций:

• About - некоторая информация об авторе и версии компонента
• Type - тип компонента, а так же настройка дополнительных параметров
• Edit - эта секция только для интерфейсных элементов. В ней указывается, какой стандартный компонент в визуальном редакторе будет отображаться при редактировании, а так же указывается соответствие св-тв из конфигурации элемента св-вам элемента в редакторе HiAsm.
• Handlers - секция переопределения редакторов свойств
• Property - секция описания всех статических св-тв элемента
• Methods - описание точек входов

About
   На данный момент информация из этой секции нигде не используется и содержит 3 поля:

• Version - версия элемента. Младший номер версии автоматически увеличивается на 1 при каждом редактировании элемента в ECreator. Поэтому в большинстве случаев следить за ней нет необходимости.
• Author - имя автора элемента. Автоматически заполняется из настроек HiAsm.
• Mail - почтовый ящик. Автоматически заполняется из настроек HiAsm.

Type
   Основная секция, определяющая базовый тип элемента и его отображение в среде.

Class - указывает к какому классу принадлежит описываемый элемент. Возможные классы элементов приведены в таблице ниже:

Имя класса	Описание
Element	простой элемент
WinElement	элемент интерфейса, который можно редактировать в Редакторе Формы
MultiElement	компонент контейнер
EditMulti	редактор MultiElement. Его невозможно выбрать непосредственно из палитры и совершенно очевидно, что использовать его в качестве базового не имеет смысла
DPElement	элементы с динамическими точками входов
DPLElement	более мощный класс для создания элементов с именованными динамическими точками входов
VTElement	элемент с отображаемым и редактируем текстом на рабочем поле проекта

Info - описание компонента (то, что отображается на вкладке Короткая справка в нижней части редактора HiAsm)

Tab - дефолтная вкладка размещения элемента в палитре. Это поле заполняется автоматически из поля Tab группы Tabs.

Inherit - имена классов, от которых наследуется элемент. Если это поле задано, то к описанию элемента при его загрузке в среде будут автоматически добавлены секции Property и Methods наследуемых классов. Количество вложений наследования не ограничено.

Interfaces - имена интерфейсов, которые предоставляет элемент.

Icon - имя св-ва из секции Property, значение которого определяет вид иконки на рабочем поле среды. Это св-во должно иметь тип combo или comboex.

Sub - дополнительные параметры элемента в зависимоссти от его типа:

• Element - если этот параметр равен Form (в ECreator отображается в виде установленного флажка), то среда всякий раз при добавлении такого элемента в рабочее поле программы будет проверять наличие в текущем контейнере визуального родителя, т.е. элемента с классом WinElement. В противном случае пользователь получит сообщение о том, что данный элемент не может быть вставлен.
• WinElement - не используется классом
• MultiElement - определяет, какой визуальный компонент будет компонентом-родителем. В качестве значения указывается имя базового класса элемента. При вставке такого контейнера в среду HiAsm автоматически поместит внутрь него родительский элемент из св-ва Sub.
• DPElement - служит для описания имен динамически создаваемых точек входа и указания какое свойство отвечает за данный тип точек(это св-во, само собой разумеется должно иметь тип integer). Формат описания точек следующий:
  Sub=(имя св-ва для точек Work)|(общее имя создаваемых точек Work),(... Event)|(... Event),(... Var)|(... Var),(... Data)|(... Data)

• DPLElement - служит для описания имен динамически создаваемых точек входа на основе списков строк. Тут каждая строка указанного св-во(св-во типа список строк ) определяет одну точку в элементе. Формат описания точек следующий:
  Sub=(имя св-ва для точек Work),(... Event),(... Var),(... Data)

• VTElement - определяет тип редактора текста: edit - в качестве редактора используется обычный Memo, syntax - в качестве редактора используется компонент с подцветкой синтаксиса.

Edit
   Эта секция используется только для класса WinElement и состоит из одного обязательного поля:

Class - имя встроенного класса, т.е. элемент, который будет отображаться на форме во время её редактирования.   Дальше следуют поля в формате: (св-во встроенного класса)= (св-во элемента) - они определяют какие св-ва вашего компонента задают его внешний вид на форме во время редактирования (стоит отметить, что речь идет только о Редакторе Форм, сам же интерфейсный компонент и его вид в EXE программе определяет программист).

   Начиная с версии 3.6 build 146, в HiAsm добавлен "пользовательский" класс с именем Custom, который позволяет вам самостоятельно отрисовывать компонент, а так же реагировать на изменение его св-тв в момент редактирования в Редакторе форм. Для него нет необходимости указывать списки сопоставляемых св-тв, т.к. они все передаются в обработчик. Подробнее об использовании этого класса читайте в статье Класс Custom

Handlers
   Начиная со 174 сборки среды была добавлена возможность привязывать пользовательские обработчики свойств. Реализация данной функциональности была сделана следующим образом:

В конфигурационном файле элемента добавилась новая секция Handlers в формате

[Handlers]
<Отработчик 1>=<Свойство 1>,<Свойство 2>...<Свойство №>
<Отработчик 2>=<Свойство 1>,<Свойство 2>...<Свойство №>
...
<Отработчик 3>=<Свойство 1>,<Свойство 2>...<Свойство №>

   В папке %hiasm%int добавлен новый каталог edit, куда помещаются обработчики (с названиями <Отработчик>.sha) ввиде схем пакета Modules с проектом "Диалог HiAsm". Сама схема должна содержать элемент hcHiAsmTrasmitter, который передает в нее текущее значение параметра и принимает новое.

   На данный момент пользовательский обработчик может быть назначен только свойствам с типом Integer, String, Real или StrList. Обработчик вызывается при нажатии кнопки "..." справа от поля редактирования св-ва.

Property
   Поля этой секции целиком определяются автором компонента и имеют следующий формат:

[+][@](Имя свойства)[(отображаемое имя)]=(описание)|(тип)|(начальное значение)[|(Список выбора)]

где:

• + - Если перед именем стоит +, то по двойному клику на компоненте будет открыт редактор свойства данного типа
• @ - Если перед именем стоит @, то пользователь сможет создать точку типа Метод с именем do(Имя свойства) через контекстное меню менеджера свойств. Очевидно, что автор компонента должен также позаботится о наличие обработчика этой точки в коде (саму точку в Файл конфигурации вносить не нужно)
• Имя свойства - имя, отображаемое в редакторе св-тв компонента. Внимание! Это имя может состоять только из букв Латинского алфавита(a-z), знака _(подчеркивание) и цифр(0-9). Если вы вставите что-то еще, то проект с вашим компонентом компилироваться не будет.
• отображаемое имя - начиная с версии 4.0 build 173 в HiAsm добавлена возможность изменять отображаемые имена свойств (имеется ввиду отображение для пользователя в панели свойств элемента). Это имя должно идти сразу после имени св-ва и заключаться в [].
• описание - описание св-ва. Тут вы можите использовать любые символы, кроме |
• тип - тип данных св-ва. Указывается индексом из таблицы, приведенной ниже:
  

  Индекс	Имя типа	Описание
  1	Integer	Число целого типа
  2	String	Строка
  3	Data	Данные переменного типа. Включают в себя - Integer, String, Real
  4	List	Выборочный тип данных (*)
  5	StrList	Список строк
  6	Icon	Иконка
  7	Real	Число с плавающей точкой
  8	Color	Цвет
  9	Script	Определяет текст скрипта на языке Basic
  10	Stream	Бинарные данные
  11	Bitmap	Картинка в формате BMP
  12	Wave	Звуковые данные в формате WAV
  13	Array	Массив. Тут в качестве (начальное значение) указывается номер типа элементов массива
  14	Enum	Перечисление значений параметра (*)
  15	Font	Шрифт
  16	Matr	Зарезервированно
  17	Jpeg	Картинка в формате JPEG
  18	Menu	Меню
  19	Code	Код на некотором языке
  20	LinkElement	Имя привязанного элемента-менеджера
  21	Flags	Список флагов

  
  (*) отличие типа List от типа Enum состоит в том, что при генерации шаблона компонента свойству с типом List будет присвоено значение от 0 до Count-1, где Count - количество элементов в списке перечислений, т.е. индекс выбранного элемента, а св-ву с типом Enum будет присвоено само его значение из списка перечисления.
  
• начальное значение - значение по-умолчанию для данного св-ва. Задаётся только для типов Integer, String ,List и Enum (в виде номера пункта начиная с 0), StrList (в виде (строка1)#13#10(строка2) и т.д), Real, Color (кроме числа поддерживаются все стандартные константы: clRed, clWindows, clYellow и т.д.)
• Список выбора - определяется только в том случае, если выбран тип List или Enum и содержит перечисление всех пунктов выбора через запятую (например: True, False). Начиная с версии 4.01 build 177 Список выбора так же используется в свойстве типа Integer, который определяет два числа, разделенных запятой для ограничения допустимого значения (например ограничение значения свойства, содержащего проценты: 0, 100)

   Начиная с версии 3.6 build 150 менеджер свойств в HiAsm поддерживает объединения в группы. Синтаксис объединения достаточно прост:

##(Имя группы)=(Описание группы)
(список св-тв, входящих в группу)
##

где:

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

## - две пустые решетки в строке означают конец группы

Methods
   Поля этой секции так же целиком определяются автором компонента и имеют следующий формат:

[*](Имя точки)[%(Индекс выбранного пункта)%]=(описание)|(тип точки)|(тип значения)

где:

• * - если перед именем метода стоит знак *, то он будет скрытым, т.е. пользователь сможет самостоятельно выбирать данную точку в панели Параметры на вкладке Точки.
• Имя точки и Описание - полностью аналогичны параметрам секции Property
• тип точки - тип точки входа. Всего может быть 4 типа: Work, Event, Var и Data, которые задаются номерами от 1 до 4 соответственно
• тип значения - определяет тип данных, которые возвращает или принимает данная точка. Этот параметр используется только при включенной опции отображения "синтаксиса" когда точки разных типов окрашены в разные цвета. Для пакетов же на базе FTCG определение типа точки является обязательным, т.к. оно влияет на правильность приведения типа данных при линковании элементов и соответственно корректность генеруемого кода
• Индекс выбранного пункта - если у элемента есть свойства типа List или Enum, то при описании метода можно использовать их значение для формирования уникального имени. Например:
  
  doOperation%OpType%=Вычисляет сумму, или разность, или... (и т.д. по списку в OpType)|1|
  

  здесь OpType - это имя свойства типа List, вместо которого при формировании кода подставляется его текущее значение (от 0 и больше в зависимости от выбранного пункта списка). Для правильной работы такого элемента необходимо реализовать в коде все методы doOperation0, doOperation1 ... doOperationN, где N это количество элементов в списке соответствующего свойства - 1.
  

Об интерфейсах
   Технически для организации интерфейса(или иными словами менеджера и клиентов к нему) нужно проделать две вещи:
1) У менеджера определить св-во Interfaces, в котором через запятую перечислить имена тех сервисов, которые он предоставляет(очевидно, что один элемент может содержать более одного сервиса), а так же определить св-во Name - имя менеджера
2) У клиентов определить св-во с типом LinkElement и с указанием имени этого самого интерфейса, по которому мы собираемся соединять их друг с другом. Стоит отметить тот факт, что среда допускает в одном св-ве указывать несколько интерфейсов, по которым данный клиент может соединяться с менеджерами, но следует помнить о том, что эти интерфейсы должны принадлежать разным элементам. Так же перед проектированием подобных элементов-клиентов стоит убедиться в наличии поддержки данного соединения используемым кодогенератором (на момент написания статьи эта поддержка была только у наследников FTCG)

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

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

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

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