Вверх ↑
Пакеты 
Разработка элемента - Конфигурация элемента

Конфигурация элемента
Описание
   Описание проектирования конфигурации элемента пакета 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-ое количество уровней вложенности)

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

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