Описание пользователя

Глава 3. Использование стандартных модулей автокомпиляции

§3.5. Окно редактора модели

§3.5.4. Описания программы и реакции блока на события

Описывается ввод фрагментов программ на языке C++, которые определяют поведение блока при наступлении различных системных событий.

Программа модели блока, формируемая модулем автокомпиляции, может состоять из большого числа вводимых пользователем фрагментов – как реакций блока на различные события, так и описаний, которые пользователь считает нужным включить в модель. Эти фрагменты добавляются и удаляются на вкладке «события» дополнительной панели окна редактора модели (рис. 339). Разбиение полной программы модели блока на отдельные фрагменты, связанные с конкретными событиями, позволяет переложить ответственность за правильную сборку полной программы на модуль автокомпиляции – пользователю достаточно указать, что именно должен делать блок при наступлении того или иного события, а модуль самостоятельно оформит этот текст в виде функции и включит в программу ее вызов в нужном месте.

Список фрагментов программы на этой вкладке организован в виде дерева, в котором события и описания объединены в группы по смыслу. Каждую группу можно раскрыть нажатием на значок «+» слева от ее названия. Перед названием каждого отдельного фрагмента в группе отображается иконка желтого цвета, если для этого фрагмента введен текст программы, и белого, если текста нет, то есть реакция на данное событие или данное описание отсутствует в модели. Иконка рядом с названием группы имеет желтый цвет, если хотя бы один фрагмент внутри нее содержит текст программы – так можно видеть заполненные события и описания даже если их группы не раскрыты. На рис. 339, например, видно, что пользователем введены тексты фрагментов программы для глобальных описаний модели, для выполнения одного такта расчета (пункт «модель» в группе «моделирование и режимы»), для реакции на запуск расчета и для каких-то реакций блока на вызов функций (группа «функции блока» не раскрыта, поэтому не видно, для каких именно). Рядом с названием каждой реакции блока на событие в скобках отображается имя константы, соответствующей этому событию в описаниях RDS. Зная имя этой константы, можно найти описание события в приложениях и изучить возможности и примеры реакции на него. Модуль автокомпиляции позволяет включить в программу реакции не на все возможные события, но для большинства моделей будет достаточно тех, что есть. Список всех реакций и описаний, которые можно ввести в автокомпилируемую модель, приведен в §3.7.

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

Чтобы понять, как именно введенные пользователем фрагменты вставляются в формируемый текст полной программы модели, необходимо представлять себе общую структуру этого текста. Этот текст содержит (см. также §3.7.1):

• команды включения необходимых для работы файлов заголовков («windows.h», «math.h» и т.п.);
• описания глобальных переменных и служебные функции, автоматически формируемые модулем согласно параметрам модели;
• автоматически формируемую главную функцию DLL, которую должна иметь каждая динамически подключаемая библиотека в Windows;
• глобальные описания пользователя, если таковые имеются;
• автоматически формируемое описание класса блока, содержащее все переменные и функции, необходимые для его работы, включая пользовательские описания полей и функций класса, если они есть;
• дополнительные пользовательские описания, если таковые имеются;
• функцию модели блока, автоматически формируемую согласно правилам RDS, содержащую оператор switch с большим количеством меток case (по одной метке на каждое событие), из которого вызываются функции реакции на события;
• введенные пользователем реакции на события, оформленные как функции-члены класса блока.

В целом, формируемый модулем автокомпиляции текст программы устроен примерно так же, как и примеры моделей блоков в руководстве программиста, за исключением того, что там для доступа к переменным блока используются макросы, а в автокомпилируемых моделях – специальные классы, и все данные блока тоже всегда оформляются как класс. Именно поэтому модуль автокомпиляции может работать только с компиляторами языка C++, а компиляторы «чистого» C для этого не подходят. Пользователь, создающий автокомпилируемые модели, может и не обращать особого внимания на структуру формируемого текста, но знание этой структуры может помочь в поиске ошибок. Если место какого-либо фрагмента в общем тексте программы покажется непонятным, всегда можно вызвать пункт меню окна редактора «модель | показать текст C++» и найти свой фрагмент в общем тексте.

Примеры моделей с реакциями на различные события рассмотрены в §3.6, здесь же мы кратко перечислим доступные в редакторе модели фрагменты с их характеристиками. Все упомянутые ниже константы и структуры подробно описаны в руководстве программиста и приложениях.

• Группа «описания» – описания и функции, не связанные непосредственно с реакциями блока на события (см. также §3.7.1):
  • «Глобальные описания» – описания глобальных переменных и пользовательских функций, а также команды включения нестандартных файлов заголовков, вставляемые перед описанием генерируемого для блока класса. Внутри функций в этих описаниях нельзя ссылаться на переменные блока: эти описания не являются частью класса блока и не имеют доступа к его полям. Чаще всего здесь размещают глобальные функции общего назначения.
  • «Описания внутри класса блока» – фрагмент, размещаемый в самом конце секции public класса блока. Здесь обычно описывают дополнительные пользовательские параметры, которые хранятся вместе с блоком, а также дополнительные функции, которым необходим доступ к статическим или динамическим переменным блока. Следует помнить, что, в отличие от настроечных параметров блока, для описанных здесь параметров модуль автокомпиляции не формирует команды загрузки и сохранения, поэтому их значения теряются при выгрузке схемы из памяти и ее последующей загрузке. Если дополнительные данные, хранимые в блоке, должны сохраняться вместе со схемой, необходимо либо переместить их в настроечные параметры, либо загружать и сохранять их вручную в реакциях на соответствующие события.
  • «Описания после класса блока» – фрагмент, размещаемый сразу после класса блока. Здесь обычно описывают функции, которым необходим доступ к классу блока, или тела функций-членов класса блока, описания которых сделаны в фрагменте «описания внутри класса блока». Можно разместить здесь и описания глобальных функций и переменных.
• Группа «создание и уничтожение» – реакции на события, связанные с появлением и исчезновением блоков:
  • «Инициализация блока» – реакция на событие RDS_BFM_INIT, возникающее в момент подключения модели к блоку: при загрузке схемы с этим блоком, при добавлении блока в схему из библиотеки, при подключении модели к блоку в окне параметров и т.п. Обычно в реакции на это событие присваивают начальные значения каким-либо дополнительным параметрам, описанным в классе блока, а также отводят дополнительную память, если она нужна модели. В автокомпилируемых моделях пользовательская реакция на это событие используется крайне редко, поскольку инициализация всех необходимых для работы блока объектов добавляется в программу модели автоматически, без участия пользователя. Следует помнить, что в реакции на событие инициализации нельзя обращаться к статическим переменным блока – это событие возникает до проверки допустимости структуры переменных, поэтому переменные блока на момент реакции могут не существовать.
  • «Очистка блока» – реакция на событие RDS_BFM_CLEANUP, возникающее перед отключением модели от блока: при выгрузке схемы из памяти, при стирании блока, при замене одной модели на другую и т.п. Обычно здесь освобождают дополнительную память, отведенную при инициализации блока. Как и реакция на событие инициализации, пользовательская реакция на очистку данных блока в автокомпилируемых моделях практически не используется – все необходимые действия добавляются в программу автоматически. Следует помнить, что в реакции на событие очистки нельзя обращаться к статическим переменным блока – это событие возникает, в том числе, и для блоков с недопустимой структурой переменных.
  • «Добавление блока пользователем» – реакция на событие RDS_BFM_MANUALINSERT, возникающее при добавлении блока в схему пользователем при помощи вставки из буфера обмена, загрузки из отдельного файла, добавления из библиотеки или с панели блоков. При загрузке блока в память в составе схемы это событие не возникает. Здесь можно, например, запросить у пользователя какие-либо параметры нового блока. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_MANUALINSERTDATA, содержащую причину добавления блока в схему.
  • «Удаление блока пользователем» – реакция на событие RDS_BFM_MANUALDELETE, возникающее перед тем, как блок или содержащая его подсистема будут удалены из схемы пользователем. При выгрузке всей схемы из памяти это событие не возникает. Здесь можно, например, предупредить пользователя о том, что данный блок важен для работы всей схемы. Отменить удаление в реакции на это событие нельзя – блок будет удален независимо от выполненных в фрагменте программы действий. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_MANUALDELETEDATA, содержащую описание действий пользователя, приведших к удалению блока.
  • «Перед выгрузкой системы» – реакция на событие RDS_BFM_UNLOADSYSTEM, возникающее перед тем, как вся загруженная в данный момент схема будет удалена из памяти из-за загрузки другой схемы, создания новой или завершения RDS. Здесь можно, например, стереть временные файлы, созданные моделью в процессе работы.
• Группа «моделирование и режимы» – реакции на события, связанные с работой модели в режиме расчета и с переключением режимов RDS:
  • «Модель» – реакция на событие RDS_BFM_MODEL, которое возникает у всех простых блоков в каждом такте расчета. В режиме расчета все модели простых блоков, запуск которых разрешен, циклически вызываются для реакции на это событие – именно так устроен расчет в RDS. Это – самое часто используемое событие в автокомпилируемых моделях. Фактически, большинство таких моделей состоит только из реакции на это событие, в которой значения выходов блока вычисляются по значениям его входов (см. пример в §3.2). Следует помнить, что реакция будет вызвана только в том случае, если запуск модели разрешен, то есть в параметрах блока включен расчет каждый такт или его первая сигнальная переменная имеет ненулевое значение.
  • «Запуск расчета» – реакция на событие RDS_BFM_STARTCALC, которое возникает при переходе RDS в режим расчета. Следует учитывать, что это событие возникает при любом запуске расчета, в том числе и при его продолжении после остановки. В этой реакции обычно выполняют какие-либо вычисления, которые не нужно выполнять постоянно на каждом такте. Например, здесь можно вычислить значения каких-либо сложных функций от настроечных параметров – настроечные параметры не могут быть изменены пользователем без выхода из режима расчета, поэтому их значения в течение всего расчета можно считать неизменными. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_STARTSTOPDATA, содержащую параметры запуска расчета, в том числе и признак того, что расчет запущен в первый раз после сброса – этот признак можно использовать для инициализации блока.
  • «Остановка расчета» – реакция на событие RDS_BFM_STOPCALC, которое возникает при выходе RDS из режима расчета. Здесь можно, например, сообщить пользователю о возникших в процессе расчета ошибках, если это необходимо.
  • «Сброс расчета» – реакция на событие RDS_BFM_RESETCALC, которое возникает сразу после сброса расчета во всей схеме или ее отдельной подсистеме (последнее возможно только в результате вызова специальных функций RDS моделями блоков – например, блоком оптимизации). Здесь обычно сбрасывают в исходные значения различные параметры блока, значения которых меняются в процессе расчета. Сбрасывать значения статических переменных не нужно, при сбросе им автоматически присваиваются заданные для них в редакторе значения по умолчанию.
  • «Режим редактирования» – реакция на событие RDS_BFM_EDITMODE, которое возникает при переходе RDS в режим редактирования и сразу после загрузки схемы (если режим редактирования не запрещен каким-либо образом, после загрузки новой схемы RDS переходит в этот режим автоматически). В реакции на это событие можно взводить какие-либо флаги, меняющие поведение блока. Например, блоки, которые сами рисуют свои изображения, могут по-разному вести себя в режимах редактирования, моделирования и расчета. Для отслеживания текущего режима можно использовать реакции на события смены режимов.
  • «Режим моделирования» – реакция на событие RDS_BFM_CALCMODE, которое возникает при переходе RDS в режим моделирования. Это событие, как и событие перехода в режим редактирования, можно использовать для отслеживания текущего режима.
  • «Изменение динамической переменной» – реакция на событие RDS_BFM_DYNVARCHANGE, которое возникает при создании и удалении динамической переменной, на которую подписался блок, а также в результате уведомления каким-либо другим блоком всех остальных об изменении значения этой переменной. Следует помнить, что это событие не возникает автоматически при записи в динамическую переменную нового значения – записавший значение блок должен явно уведомить все остальные блоки, использующие эту переменную, о том, что ее значение изменилось. В автокомпилируемых моделях это делается вызовом у переменной функции-члена NotifySubscribers: например, после изменения значения переменной DynVar1 необходимо сделать вызов «DynVar1.NotifySubscribers();», чтобы у всех блоков, подписанных на эту переменную (то есть блоков, запросивших к ней доступ), возникло событие RDS_BFM_DYNVARCHANGE. В функцию, формируемую для реакции на это событие, передается специальный идентификатор типа RDS_PDYNVARLINK, указывающий на изменившуюся переменную. Примеры моделей, реагирующих на изменение динамической переменной и уведомляющих другие блоки о таком изменении, рассмотрены в §3.6.3.
• Группа «мышь и клавиатура» – реакции на действия пользователя:
  • «Нажатие кнопки мыши» – реакция на событие RDS_BFM_MOUSEDOWN, которое возникает в режимах моделирования и расчета при нажатии пользователем кнопки мыши в пределах изображения блока, находящегося на видимом активном слое, если в параметрах этого блока разрешена реакция на мышь. В этой реакции можно не только определить факт нажатия кнопки, но и узнать, в какой части изображения блока в этот момент находился курсор. Пример модели, реагирующей на нажатие кнопки мыши, приведен в §3.6.11. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_MOUSEDATA, содержащую идентификатор нажатой кнопки, координаты курсора мыши и т.п..
  • «Отпускание кнопки мыши» – реакция на событие RDS_BFM_MOUSEUP, которое возникает в режимах моделирования и расчета при отпускании ранее нажатой пользователем кнопки мыши над изображением блока. Это событие – парное к предыдущему. Чаще всего оно используется при создании блоков, изображающих кнопки: при нажатии кнопки мыши блок изображает кнопку в нажатом состоянии до тех пор, пока не получит информацию об отпускании кнопки. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_MOUSEDATA, содержащую идентификатор кнопки, координаты курсора мыши и т.п.
  • «Двойной щелчок мыши» – реакция на событие RDS_BFM_MOUSEDBLCLICK, которое возникает в режимах моделирования и расчета при двойном щелчке на изображении блока, находящегося на видимом активном слое, если в параметрах этого блока разрешена реакция на мышь. Следует учитывать, что из-за природы двойного щелчка перед реакцией на это событие блок сначала среагирует на нажатие и отпускание кнопки. Как и для остальных событий, связанных с мышью, в функцию реакции передается указатель на структуру RDS_MOUSEDATA.
  • «Перемещение мыши» – реакция на событие RDS_BFM_MOUSEMOVE, которое возникает в режимах моделирования и расчета при перемещении курсора мыши над изображением блока, находящегося на видимом активном слое, если в параметрах этого блока разрешена реакция на мышь. В параметрах блока можно разрешить реакцию на это событие только при нажатых кнопках мыши или независимо от состояния кнопок (последнее используется реже). Эта реакция чаще всего используется для создания блоков, имитирующих различные рукоятки, которые пользователь может двигать, меняя значения переменных. В функцию реакции на это событие тоже передается указатель на структуру RDS_MOUSEDATA.
  • «Нажатие клавиши» – реакция на событие RDS_BFM_KEYDOWN, которое возникает в режимах моделирования и расчета при нажатии какой-либо клавиши на клавиатуре, если окно подсистемы с этим блоком внутри находится на переднем плане и в параметрах блока разрешена реакция на клавиатуру. В реакции на это событие можно выполнять какие-либо действия по нажатиям разных клавиш, создавая таким образом «виртуальные пульты управления». В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_KEYDATA, содержащую код клавиши, флаги и т.п.
  • «Отпускание клавиши» – реакция на событие RDS_BFM_KEYUP, которое возникает в режимах моделирования и расчета при отпускании ранее нажатой клавиши на клавиатуре, если окно подсистемы с этим блоком внутри находится на переднем плане и в параметрах блока разрешена реакция на клавиатуру. Это событие – парное к предыдущему. В функцию, формируемую для реакции на это событие, тоже передается указатель на структуру RDS_KEYDATA.
• Группа «функции блока» объединяет реакции на вызовы функций блока, внесенных в список функций на вкладке «функции». В этой группе для каждой внесенной в список функции можно ввести текст программы реакции. Если в редакторе модели не добавлено ни одной функции блока, группа будет пустой. Примеры моделей, использующих функции блоков, приведены в §3.6.13.
• Группа «загрузка и запись данных» – события, связанные с загрузкой и сохранением данных блока и всей схемы:
  • «Загрузка данных блока» – реакция на событие RDS_BFM_LOADTXT, которое возникает при загрузке параметров блока в момент загрузки схемы или при чтении данных этого блока из файла в библиотеке или из буфера обмена при вставке его в схему. В функцию реакции на это событие передается строка текста, сформированная этим же блоком при сохранении, которую модель должна разобрать, получив из нее все необходимые значения и присвоив их нужным параметрам. Эта реакция редко используется а автокомпилируемых моделях, поскольку загрузка значений настроечных параметров блока производится автоматически, и никаких дополнительных реакций для этого не требуется. Создавать эту реакцию нужно только в том случае, если у блока есть какие-то свои, нестандартные, параметры (например, оформленные как поля класса блока), которые необходимо сохранять и загружать вручную. Кроме того, ее можно использовать для выполнения каких-либо действий сразу после загрузки настроечных параметров блока – пример этого приведен в §3.6.8.
  • «Запись данных блока» – реакция на событие RDS_BFM_SAVETXT, которое возникает при сохранении параметров блока в момент сохранения всей схемы или при записи данных этого блока в отдельный файл или в буфер обмена. Это событие – парное к предыдущему. Для блоков, в которых нет нестандартных параметров, реакция на него не требуется – сохранение настроечных параметров добавляется в программу модели автоматически.
  • «Перед сохранением схемы» – реакция на событие RDS_BFM_BEFORESAVE, возникающее у всех блоков непосредственно перед сохранением схемы в файл. Эта реакция используется крайне редко, в основном – в блоках, вносящих временные изменения в схему, чтобы они могли их отменить перед сохранением.
  • «После сохранения схемы» – реакция на событие RDS_BFM_AFTERSAVE, возникающее у всех блоков сразу после сохранения схемы в файл. Используется крайне редко.
  • «После загрузки схемы» – реакция на событие RDS_BFM_AFTERLOAD, возникающее у всех блоков сразу после загрузки схемы из файла. Обычно используется для инициализации каких-либо журналов событий (пример такой модели приведен в §3.6.13.4).
• Группа «загрузка и запись состояния блока» – события, связанные с запоминанием состояния блока и его восстановлением по команде:
  • «Загрузка состояния блока» – реакция на событие RDS_BFM_LOADSTATE, возникающее у блока, если его текущее состояние восстанавливается по команде от модели какого-либо другого блока. Сохранение и загрузка состояния одного или нескольких блоков используется в RDS для управления расчетом: вызовом сервисной функции rdsSaveSystemState можно сохранить в памяти текущее состояние одного или нескольких блоков, а затем, вызвав rdsLoadSystemState, вернуть эти блоки в запомненное состояние (подробнее это описано в §2.14.3 руководства программиста. Реагируя на событие загрузки состояния, модель должна загрузить значения всех тех параметров, которые она сохранила в реакции на событие RDS_BFM_SAVESTATE. Для загрузки должна использоваться сервисная функция rdsReadBlockData. Следует учитывать, что текущие значения статических переменных блока восстанавливать не нужно – они сохраняются и восстанавливаются автоматически.
  • «Запись состояния блока» – реакция на событие RDS_BFM_SAVESTATE, возникающее у блока, если его текущее состояние сохраняется по команде от модели какого-либо другого блока. Это событие – парное к предыдущему. Реагируя на него, модель должна сохранить значения всех изменяющихся со временем параметров блока, чтобы потом, в реакции на событие RDS_BFM_LOADSTATE, восстановить их. Для сохранения должна использоваться сервисная функция rdsWriteBlockData.
• Группа «реакции подсистемы» объединяет реакции на различные действия пользователя с окном подсистемы:
  • «Действия с окном подсистемы» – реакция на событие RDS_BFM_WINDOWOPERATION, возникающее у подсистемы, если ее окно открывается или закрывается, а также у блоков других типов, если открывается или закрывается окно их родительской подсистемы. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_WINOPERATIONDATA, содержащую текущий режим RDS, дескриптор окна и т.п.
  • «Нажатие кнопки мыши», «отпускание кнопки мыши» и др. – реакции на события, аналогичные событиям из группы «мышь и клавиатура», но вызываемые не для блоков, а для подсистем при действиях мышью в свободном от блоков месте рабочего поля их окон. Если, например, ни один из блоков не среагировал на нажатие кнопки мыши, и для подсистемы разрешена реакция на мышь в свободных областях ее окна, будет вызвана реакция модели этой подсистемы. Поскольку автокомпилируемые модели подсистем на практике не применяются, события из этой группы используются крайне редко.
• Группа «внешний вид блока» – события, связанные с изображением блока и его положением на рабочем поле:
  • «Размер блока изменен» – реакция на событие RDS_BFM_RESIZE, возникающее у блоков, внешний вид которых рисуется программно, сразу после изменения размеров такого блока пользователем. В этой реакции можно отменить изменение размеров или скорректировать заданные пользователем размеры – например, изменять ширину блока синхронно с высотой, чтобы пропорции блока оставались неизменными. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_RESIZEDATA, содержащую новые размеры блока и маркер выделения, который пользователь перетащил, чтобы изменить размеры.
  • «Проверка изменения размера» – реакция на событие RDS_BFM_RESIZING, возникающее у блоков, внешний вид которых рисуется программно, в процессе изменения размера такого блока перетаскиванием одного из восьми маркеров выделения блока, то есть при каждом движении курсора мыши. Чаще всего эта реакция используется для создания визуальной обратной связи при изменении размеров: в ней можно корректировать размер инверсного прямоугольника, которым обозначается новый размер блока в процессе перетаскивания маркеров. В функцию, формируемую для реакции на это событие, тоже передается указатель на структуру RDS_RESIZEDATA. Пример модели, реагирующей на это событие, приведен в §3.6.5.
  • «Блок перемещен» – реакция на событие RDS_BFM_MOVED, возникающее у блока сразу после перемещения его пользователем или программным вызовом из модели другого блока. Реакция на это событие используется достаточно редко – чаще всего, для автоматического перемещения каких-либо блоков вместе с данным. Модель блока не может отменить перемещение блока в этой реакции. В функцию, формируемую для реакции на событие, передается указатель на структуру RDS_MOVEDATA, содержащую новые и старые координаты блока и причину его перемещения.
  • «Рисование блока» – реакция на событие RDS_BFM_DRAW, возникающее у блоков, внешний вид которых рисуется программно, при обновлении окна подсистемы с этим блоком. В реакции на это событие модель блока должна нарисовать в окне подсистемы его изображение, используя для этого сервисные функции RDS или графические функции API Windows. Следует помнить, что для включения программного рисования в окне параметров блока должен быть установлен флаг «внешний вид блока – определяется функцией DLL», в противном случае блок будет изображаться либо векторной картинкой, либо прямоугольником с текстом, и реакция на это событие вызываться не будет. Функции рисования и различные их особенности подробно рассматриваются в §2.10 руководства программиста, примеры моделей блока, рисующих изображения программно, приведены в §3.6.5. В функцию, формируемую для реакции, передается указатель на структуру RDS_DRAWDATA, содержащую оконные координаты, по которым необходимо нарисовать изображение, а также другие необходимые для рисования параметры.
  • «Дополнительное рисование блока» – реакция на событие RDS_BFM_DRAWADDITIONAL, возникающее у всех блоков при обновлении окна их родительской подсистемы после того, как все изображения уже нарисованы. В отличие от события рисования RDS_BFM_DRAW, которое возникает только у блоков, внешний вид которых рисуется программно, это событие возникает у всех блоков независимо от их внешнего вида: у рисуемых программно, у имеющих векторную картинку и у изображаемых прямоугольником с текстом. В реакции на него можно вывести поверх изображения блока какую-либо дополнительную информацию – например, иконки, сигнализирующие об ошибках. В функцию, формируемую для реакции на событие, тоже передается указатель на структуру RDS_DRAWDATA. Пример модели блока, реагирующего на это событие, приведен в §3.6.10.
• Группа «сеть» – события, связанные с встроенным в RDS механизмом обмена данными по сети (более подробно сетевые механизмы RDS описаны в §2.15 руководства программиста, здесь они не рассматриваются):
  • «Получены данные» – реакция на событие RDS_BFM_NETDATARECEIVED, возникающее при получении блоком каких-либо данных по сети от другого блока. В функцию, формируемую для реакции, передается указатель на структуру RDS_NETRECEIVEDDATA, содержащую принятые данные и описание отправившего их блока и сервера, через который идет обмен данными.
  • «Соединение установлено» – реакция на событие RDS_BFM_NETCONNECT, возникающее после того, как соединение с сервером, запрошенное моделью блока при помощи сервисной функции RDS rdsNetConnect, успешно установлено. Обычно в этой реакции взводят какой-либо внутренний флаг в параметрах блока, указывающий на то, что теперь можно передавать данные другим блокам. В функцию, формируемую для реакции, передается указатель на структуру RDS_NETCONNDATA, содержащую параметры установленного соединения.
  • «Соединение разорвано» – реакция на событие RDS_BFM_NETDISCONNECT, возникающее после разрыва ранее установленного моделью блока соединения с сервером. Соединение может быть разорвано по разным причинам. Если соединение было разорвано по инициативе модели блока вызовом rdsNetCloseConnection, оно останется разорванным, в противном случае RDS будет пытаться самостоятельно восстановить это соединение без каких-либо запросов от модели. Обычно в этой реакции взводят какой-либо внутренний флаг в параметрах блока, указывающий на то, что передавать данные другим блокам сейчас нельзя. В функцию, формируемую для реакции, тоже передается указатель на структуру RDS_NETCONNDATA.
  • «Данные приняты сервером» – реакция на событие RDS_BFM_NETDATAACCEPTED, возникающее после того, как сервер, через который блок отправил свои данные, подтвердил их получение. Это событие возникает только в том случае, если, передавая данные, блок запросил у сервера подтверждение их приема в параметрах функций rdsNetBroadcastData или rdsNetSendData. Следует помнить, что подтверждение выдается при получении данных сервером, а не блоком-получателем данных – серверу еще только предстоит отправить данные получателю. Эту реакцию можно использовать для организации в блоке собственной очереди передачи данных, не связанной с очередью RDS, чтобы блок не передавал очередную порцию данных, пока не получит от сервера подтверждение приема предыдущей. В функцию, формируемую для реакции, передается указатель на структуру RDS_NETACCEPTDATA, содержащую параметры сетевого соединения и идентификатор блока данных, получение которого подтверждается.
  • «Ошибка сети» – реакция на событие RDS_BFM_NETERROR, возникающее у блоков, участвующих в приеме или передаче данных, при возникновении различных ошибок в сетевом соединении. Большую часть таких ошибок RDS обрабатывает самостоятельно, поэтому, как правило, в моделях блоков реакция на это событие не требуется. В функцию, формируемую для реакции, передается указатель на структуру RDS_NETERRORDATA, содержащую параметры сетевого соединения и код ошибки.
• Группа «разное» – различные события, не вошедшие в одну из уже описанных групп:
  • «Переименование блока» – реакция на событие RDS_BFM_RENAME, возникающее после переименования блока. В функцию, формируемую для реакции, передается строка с именем блока до переименования. В реакции на это событие можно, например, изменить имена каких-либо связанных с блоком объектов, которые формируются из имени блока.
  • «Вызов настройки» – реакция на событие RDS_BFM_SETUP, возникающее в режиме редактирования при вызове функции настройки блока. Редактор модели позволяет достаточно простыми средствами создавать окно для задания настроечных параметров блока без необходимости вручную писать программу для этой реакции. Реакцию на это событие можно использовать в тех случаях, когда встроенных в редактор модели возможностей окна настройки не хватает. Следует помнить, что если в редакторе модели одновременно описать настроечные параметры блока с окном их настройки и ввести текст для реакции на событие RDS_BFM_SETUP, сначала будет открыто окно настройки, созданное средствами редактора, а введенная программа реакции вызовется только после закрытия этого окна кнопкой «OK» (кнопка «отмена» заблокирует вызов реакции) – пример такого использования этой реакции приведен в §3.6.8.
  • «Реакция на таймер» – реакция на событие RDS_BFM_TIMER, возникающее при срабатывании таймера блока, созданного его моделью при помощи сервисной функции RDS rdsSetBlockTimer. В функцию, формируемую для реакции на это событие, передается идентификатор сработавшего таймера. Реакция на таймер может использоваться для периодического или отложенного на заданное время выполнения моделью блока каких-либо действий.
  • «Обновление окон блока» – реакция на событие RDS_BFM_WINREFRESH, возникающее при необходимости обновить открытые окна, принадлежащие данному блоку. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_WINREFRESHDATA, в которой содержится идентификатор таймера, вызвавшего обновление окон (если обновление вызвано таймером), и в которую функция модели может записать время, потраченное ей на рисование содержимого этих окон, для учета в алгоритме подстройки частоты обновления. Создание моделей блоков, открывающих и поддерживающих собственные окна – довольно сложная задача, требующая использования блокировки данных, поэтому в автокомпилируемых моделях эта реакция практически не используется (желающие могут изучить §1.8 руководства программиста).
  • «Всплывающая подсказка» – реакция на событие RDS_BFM_POPUPHINT, возникающее при запросе у блока текста всплывающей подсказки, если курсор мыши задержался в пределах изображения этого блока (при этом вывод всплывающей подсказки должен быть разрешен в параметрах блока). В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_POPUPHINTDATA, в которой содержатся координаты курсора мыши и текущие параметры изображения блока, и через которую модель возвращает параметры показа подсказки, если это необходимо. Текст подсказки возвращается в RDS при помощи сервисной функции rdsSetHintText. В этой реакции можно формировать не только статичные всплывающие подсказки, но и подсказки, изменяющиеся в зависимости от положения курсора на изображении блока (см. §3.6.9).
  • «Вызов контекстного меню» – реакция на событие RDS_BFM_CONTEXTPOPUP, возникающее при открытии контекстного (то есть вызываемого по правой кнопке мыши) меню блока. В этой реакции модель может добавить в это меню свои собственные пункты. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_CONTEXTPOPUPDATA, в которой содержится признак нахождения RDS в режиме редактирования (чаще всего пункты контекстного меню в режиме редактирования и в режимах моделирования и расчета не совпадают). Примеры моделей, добавляющих свои пункты в контекстное меню, приведены в §3.6.12.
  • «Выбор пункта меню» – реакция на событие RDS_BFM_MENUFUNCTION, возникающее при выборе пользователем одного из пунктов, добавленных моделью блока в его контекстное меню или в главное меню RDS. В функцию, формируемую для реакции на это событие, передается указатель на структуру RDS_MENUFUNCDATA, описывающую выбранный пользователем пункт.
  • «После создания статических переменных» – фрагмент программы, вызываемый немедленно после автоматически формируемой модулем автокомпиляции реакции на событие проверки типа статических переменных RDS_BFM_VARCHECK, если фактические типы переменных блока совпали с заданными в редакторе модели. Если переменные блока отличаются по типам и последовательности от списка, заданного на вкладке «переменные» левой панели редактора, этот фрагмент, как и все остальные реакции на события, вызываться не будет. В моделях блоков крайне редко возникает необходимость выполнить какие-либо действия после успешной проверки соответствия переменных блока ожиданиям модели, поэтому данная реакция практически не используется.
  • «Прочие события» – общая реакция на все остальные события, возникающие в схеме. Эти события используются значительно реже перечисленных выше, поэтому отдельные пункты в список для них не добавлены. В общую функцию, формируемую для реакции на эти события, передается идентификатор конкретного события и указатель общего вида, который нужно привести к типу, соответствующему параметрам события. Полный список событий приведен в А.2 приложений.

Для перечисленных выше событий автоматически формируются функции следующего вида:

  void rdsbcppBlockClass::имя_функции(параметры)
  {
    текст пользователя
  }

где rdsbcppBlockClass – имя класса блока (оно всегда одно и то же во всех моделях, несмотря на то, что содержимое этого класса изменяется от модели к модели), имя_функции – жестко заложенное в модуль автокомпиляции имя функции реакции на данное событие, параметры – жестко заданный для каждого типа события набор параметров, текст пользователя – введенный пользователем на вкладке редактора модели фрагмент текста программы. Все возможные варианты создаваемых функций перечислены в §3.7. Заголовок такой функции со всеми ее параметрами отображается в верхней части вкладки, на которой вводится текст реакции (рис. 340) – таким образом, пользователь может понять, какие параметры функции он может использовать в тексте.

Для описаний, в отличие от реакций на события, функции не генерируются – введенный пользователем текст вставляется непосредственно в программу внутри или снаружи описания класса блока.