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

На данном этапе развития ГУИ я планирую сделать так.

Завести структуру сообщения в виде


Ну и отправлять сообщения из любого потока ОС, которое что-то хочет отправить ГУИ. А последняя пусть сама разбиарается, что с этим сообщением делать (игнорировать, построить очередную точку на диаграмме, "нажать" кнопку...)...

Подумайте сразу о параметрах сообщения. Ну, типа координат нажатия на экран, кода нажатой клавиши, значения АЦП...

Совершенно верно! Поскольку очередь сообщений OS::channel предназначена для передачи данных конкретного типа (а это ее преимущество, чтобы не плодить сущности с указателями void*), необходимо как-то унифицировать тип сообщения. Пока думаю...

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

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

Реализация механизма следующая. Сразу приведу весь код, ниже будет дано пояснение:


Ключевыми частями являются функция generate_id() и шаблон msg_wrapper. Функция generate_id() при каждом вызове возвращает целое с новым значением (увеличенным на 1 в данном случае), и служит, как ясно из названия, для генерации уникальных идентификаторов. Внутри шаблона msg_wrapper есть механизм получения и предъявления уникального (для каждого типа) идентификатора. Реализован с помощью пары функций get_class_id() и get_id().

Функция get_class_id(), собственно, и производит получение уникального идентификатора и его хранение. Сделано это на основе свойства статических локальных переменных инициализироваться "по месту":

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

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

Ну, далее пара функций - передачи и приёма. Передача:


Тут всё просто. Функция принимает указатель на тело сообщения и адрес объекта назначения. Поскольку у нас назначением является любой объект из иерархии виджетов, то в качестве типа объекта взят самый главный предок всей этой иерархии. Передаётся при вызове, разумеется, адрес конкретного объекта, в вышеописанной схеме GUI - адрес виджета под фокусом. Далее, внутри функции передачи конструируется собственно сообщение на основе обёртки msg_wrapper (ничего особенного тут не делается, просто инициализируется указатель на тело сообщения, накладные расходы минимальны) и посылается по указанному адресу - вызов той самой важной функций on_message(). В коде такая передач выглядит так:



Приём выглядит так (пример приводился выше, повторяю для связности изложения):


Здесь на входе проверяется соответствие типа сообщения ожидаемому; если соответствует, то дальше производится обработка тела сообщения. Соответствие выражается в значении возвращаемого указателя функции check_msg(). Если сообщение соответствует ожидаемому, то возвращается указатель на тело сообщения, если не соответствует, то возвращается ноль:


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

Таким образом осуществляется фильтрация сообщений. Это позволяет выстроить систему передачи сообщений, не "привязываясь" к конкретным типам, и в дальнейшем расширять сколько угодно перечень передаваемых сообщений, ничего не переделывая в этом коде. В примере выше при приёме ожидается сообщение от устройств ввода (в данном случае ими являются кнопки прибора и энкодер). Это поведение по умолчанию для всех виджетов. Если нужно для какого-то виджета изменить поведение, достаточно, как уже говорилось, для него переопределить функцию on_message(). Вот пример, как в одном из виджетов обрабатываются свои сообщения:


Очень важный момент - последняя ветка else. Если этого не сделать, то все сообщения, которые не обработаны, дальше не пойдут, когда данный виджет под фокусом. Внешне это будет выражаться так, что данный виджет не будет реагировать на устройства ввода (т.к. в вышеприведённой функции on_message() сообщения от устройств ввода не обрабатываются). Если их переслать дальше, то сообщения попадут в TWidget::on_message() (показанную выше) и там будут обработаны. Если требуется какая-то иная их обработка, то можно её реализовать в этой же функции, не передавая дальше. Словом, тут полная свобода действий, расширяемость, хорошая управляемость и очень небольшие накладные расходы.

Напоследок замечание (это больше для haker_fox). Не следует путать сообщения, передаваемые по вышеописанной схеме, с сообщениями, передаваемыми через средства межпроцессного взаимодействия (типа OS::channel), механизмы реализации и назначение совершенно разные. Вариант send_message/check_msg - это передача сообщения в главном цикле GUI от источников к виджетам. Передача эта синхронная - в момент передачи сообщение и принимается, и обрабатывается - это всё одна и та же цепочка вызовов функций. А передача сообщений через OS::message или OS::channel - это передача асинхронная, потокобезопасная и через промежуточный объект, в котором хранится тело сообщения. Передавать через send_message() из другого процесса можно, но это небезопасно с точки зрения межпроцессного взаимодействия.

Собственно, GUI и OS - вещи несколько ортогональные. GUI - это, как правило один из процессов (потоков, задач), крутится в своём цикле. Если требуется передавать ему сообщения из других процессов программы, то это логично сделать, например, через OS::channel, организовав очередь сообщений, и уже в процессе, в котором крутится GUI, извлекать сообщения из очереди, преобразовывать их и передавать по вышеописанной схеме виджетам.

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

dxp, спасибо большое за подробнейшее разъяснение! Вникаю

возможно я не до конца осознал всю радость от знания типа объёктов, но чем хуже использовать просто int в качестве сообщений, у самого базового класса Widget сделать виртуальный handle(int event), за который и дергать потом все виджеты подряд.
а уже в этом обработчике доставать откуда надо необходимые данные, если нужно:
int handle(int event){
switch (event){
case EVENT_KEYBOARD: int key = get_key(); ...
...
}
так, насколько я понимаю, в FLTK сделано.

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

К тому же, как сделать фильтрацию? Вот дёрнули handle() для текущего виджета - так эта функция должна уметь обрабатывать все события. Можно, конечно, завести систему кодирования на основе этого передаваемого инта и анализировать значения. Но это будет "закат Солнца вручную" - как раз примерно то, что делает схема передачи сообщений из предыдущего моего поста.

Уважаемый dxp, правильно ли я понял, что на этой же идее у Вас реализована передача информации меджу элементами GUI. Имеется в виду следующее: выбор какого-то пункта меню может блокировать доступ к другим элементам.

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

Говорить, что передаётся информация между виджетами тут нельзя - этого нет. Информация передаётся от входных сигналов виджетам, задача которых адекватно реагировать и отображать реакцию на устройстве визуализации.

Не очевидная логика.
Подвергать GUI потоку событий от реалтайм задач это значит перегрузить процессор лишней работой либо принудить задачи подстраиваться под GUI и все время беспокоиться о профайлинге GUI.
Надежней в самой задаче GUI планировать обращение за информацией к другим задачам.
Тогда и ивентов становиться гораздо меньше, упрощается их парсинг и поддержка GUI проще.
Вон в uc/GUI всего 32 базовых сообщения.
И хватает за глаза, это учитывая, что там развитый оконный движок наподобие Windows.

Спасибо, dxp.
Поясните, пожалуйста, как Вы делаете именно связь между элементами GUI для управления. По нажатию кнопки выбран элемент из списка №1 (режимы работы). Есть связанный со списком №1 список №2 (специфические (уникальные) для данного режима подрежимы). Как в этом случае делается переключение на нужный список №2.
Как-то так:

Ну, т.е. что-то вроде системы меню? Это несколько другая тема, чем передача сообщений. Тут тоже может быть несколько реализаций. Я делаю связь через промежуточный объект Target. При создании пункта меню ему присваивается объект Target, который представляет собой простой объект из иерархии таржетов. Все их объединяет метод (виртуальная функция) exec(), которая и вызывается внутри метода объекта пункта меню, отвечающего за реакцию на нажатие соответсвующей кнопки. Схема действий проста: внутри переключается фокус и вызывается перерисовка, а также выполняются все сопутствующие действия.

Если приводить аналогию из С, то этот способ похож на связть через указатель на функцию, которая и выполняет действия. Тут просто эта функция "завёрнута" в объект Target, что делает использование более безопасным и удобным (можно хранить внутри этого объекта какие-то служебные переменные). Использование промежуточных объектов позволяет гибко настроить целевые действия при активации виджета. Если не очень понятно описано, скажите, пример приведу (сейчас его нет под рукой).

AlexandrY, именно так и делается, см самый первый мой пост в этой теме - главный цикл GUI. Все сообщения посылаются из него с его темпом.

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

Да, давайте обсудим недостатки простых примеров, приведённых для упрощения понимания. Ясно, что ничего не мешает этот цикл сделать так, как хочется - например, создать очередь сообщений от других процессов. К тому же, даже в том примере цикл составляет 40 мс, этого вполне достаточно для комфортной реакции GUI на события - врядли вы успеете заметить торможение при обновлении информации, если, конечно, не рубитесь в Unreal Tournament.

Я думаю задержка там концептуально поставлена, а не для простоты.
Она именно дает GUI передохнуть.
Скорее всего жертвуется событиями от клиентских для GUI задач.

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

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

Вообщем преимущества продемонстрированной реализации весьма спорны, либо она уж очень упрощена