QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Вопрос не в необходимой частоте вывода на экран, а в том что каждый внешний (из другой задачи) ивент вы обрабатываете по всей цепочке виджетов заново.
По какой цепочке? Цепочке, состоящий из чего? Покажите? Объясните, с чего вы сделали такой вывод?
1.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Итого куча холостых циклов.
2.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Вот и ставите задержку чтоб не перенапрягать GUI холостой работой.
3.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

А затора избегаете пропуском ивентов. Может очищаете буфер очереди или еще что.
Аж целых три сильных заявления! И ни одно не имеет даже намёка на обоснование. Это ваши
фантазии, ничего этого там нет. Может, перестанете уже фантазировать и попробуете разобраться в том коде, который я привёл (если что-то не понятно, готов ответить на вопросы). А если не желаете, считаете это ниже своего достоинства, то тогда прошу перестать писать комментарии, содержание которых не имеет к действительности никакого отношения, и демонстрирующие непонимание комментируемого.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Это уж вам виднее. Вы ж свою реализацию не выкладываете.

Уже практически всё выложил. А вы и не заметили.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Про доставку я уже говорил. У Microchip-а просто есть глобальный связный список виджетов. Все идентификаторы событий сведены в одном заголовочном файле. Просто и понятно.
Понятно. Самый примитивный вариант. На С по-другому особо и не разбежишься. При добавлении и/или удалении события придётся ручками следить за соответствием идентификаторов. Закат Солнца вручную. Именно то, от чего всегда хотелось уйти - пусть машина этим занимается, она не ошибается. Другое дело, что используемый инструментарий не позволяет.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

При отладке какой бы релиз библиотеки не взяли каждый определенный числовой идентификатор всегда соответствует одному и тому же событию.
Не надо шерстить все исходники чтобы отыскать все старые и новые типы событий для того чтобы правильно их описать в логе.
И здесь всё соответствует. А в отладочный лог надо писать текстовую информацию, а не какие-то маловразумительные числа, чтобы потом руками их сопоставлять.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Кстати, упор на фокус тоже не очень понятен. Если экран с тачскрином, то зачем вообще иметь такой атрибут как фокус?
Если. А если нет? Показан простой пример. Тем не менее, прекрасно работающий. Будет тачскрин, будет чуть иная реализация.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Может быть это синоним привязки видджетов ввода к виджетам вывода? Но тогда фокусов должно быть много.
Сколько угодно. В данном примере один. Выше описывал вариант, когда может быть несколько. Ничего ничему не противоречит, не мешает, расширяется сколько угодно в любую сторону без переделки "каркаса".
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Вообщем я то выложу свои исходники, но только после того как выложите вы свои.

Во-первых, я и не просил ваши исходники. Вы цикл критиковали, я попросил ваш вариант цикла, лишённого недостатков критикуемого. Принцип, псевдокод - компилировать его никто не будет.
Во-вторых, я-то свой код уже практически выложил. Иерархия виджетов, схема передачи сообщений им. Вам что, ещё реализации методов draw() каждого виджета показать? Весь проект GUI представлен (кроме уровня вывода на устройство визуализации). Те, кто это понял, уже давно дали оценку. Кто ещё не вник, но хочет разобраться, пытаются это сделать. Кому это без разницы, те проходят мимо. Вы же, не разобравшись, наводите критику, содержание которой не имеет никакого отношения к действительности - выдуманы какие-то сущности и подвергаются критике.
Да, этот GUI такой маленький, что вы и не заметили, что это практически всё (остальное рюшечки). Да, такой "примитивный", что кода всего на пару экранов. Тем не менее, схема уже обкатана на двух серьёзных приборах и отлично себя зарекомендовала. Результирующего кода, конечно, гораздо больше (несколько тысяч строк), но это реализация функциональности виджетов.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

А то из коротких постов так и не понятно насколько развита ваша GUI и что умеет.
Несколько раз уже всё обсосано. Повторяю ещё раз. Имеет цикл обработки входящих событий, умеет передавать сообщения от событий виджетам, реализует требуемое поведение виджетов. Это основные функции любого GUI. При этом код весьма компактный, очень простой (для человека, свободно читающего на С++), сколько угодно расширяемый по основным функциям.
QUOTE (AlexandrY @ Sep 13 2012, 02:58)

Много вопросов остается.
Например, действительно ли там нужна была такая масштабируемость, что потребовалось автоматическая генерация идентификаторов?
Во-первых, не масштабируемость, а расширяемость. Расширяемость нужна всегда.
Во-вторых, не автоматическая генерация идентификаторов, а система передачи сообщений с проверкой соответствия. И уж как это сделано внутри - дело пятое. Не туда смотрите, не там акценты расставляете.
* * *
QUOTE (mdmitry @ Sep 12 2012, 20:59)

Пример был бы интересен.
У меня элементы меню - объекты с соответствующими свойствами. Обработка клавиш - вызов виртуальной функции для элемента. Вопрос как эффективно (красиво) обеспечить управление видом и содержанием элемента меню (ведомого) (или листбокса, едитбокса) в зависимости от состояния другого элемента (ведущего). Мое решение ассоциируется у меня с костылями (некрасиво, неэффективно).
Не очень понял, что именно требуется. Вы имеете в виду вариант, когда, скажем, перемещаем курсор по меню от одного пункта к другому, и при этом где-то рядом отрисовывается подменю, каждый раз другое (у каждого пункта меню своё подменю)? Этот вариант? Или что-то иное? Объясните словами поподробнее, что должно быть на экране, как оно должно реагировать на события?
* * *
QUOTE (haker_fox @ Sep 13 2012, 06:12)

1. Перересовке виджетов (весь экран перерисовывать нецелесообразно, надо подсмотреть в какой-нибудь библиотеке красивый алгоритм).
Это в большей степени зависит от особенностей аппаратуры визуализации, проще говоря, от контроллера дисплея (хотя не всегда он есть). Например, SSD1963 хорошо приспособлен для заливки прямоугольных фрагментов, но не имеет теневого буфера. Поэтому тут нужно по месту быстро обновлять изменившиеся фрагменты. В другом приборе у меня был теневой буфер в SDRAM и возможность быстро залить этот буфер в рабочий буфер, с которого идёт рефреш. Тут без разницы, сколько информации на экране вы меняете - всё равно перезаливается весь буфер, но происходит это очень быстро (800х600 за 2.4 мс) в паузах между рефрешем очередного кадра (там VESA). Поэтому не ищите универсального решения - в каждом случае свои особенности, плясать тут приходится от особенностей доступной аппаратной части видеовывода.
QUOTE (haker_fox @ Sep 13 2012, 06:12)

2. Получение данных "в ГУИ" от клавиатуры, АЦП и т.п. Здесь уже алгоритм предложен, но нужно все еще раз обдумать и "вживит" в свою реализацию.
Для начала возьмите, как есть и сделайте простейший вариант - обработка событий от кнопок парой виджетов. Когда заработает, сразу поймёте, что хорошо, что нет, что нравится, а что не нравится, чего не хватает, а что лишнее. И увидите вариант, который вам подойдёт лучше всего.