Что-то в таком виде:

Список1: картофель морковь огурец
Список2: зависит от элемента Списка1
Список3: зависит от элемента Списка2

Интересно, как организовать в этом случае данные эффективно?
Я организовывал каждый из списков через структуры с массивами и указателями для взаимосвязи. Не очень удобно.


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

Это предмет для критики, обсуждения.
Мне GUI не приходилось разрабатывать, поэтому есть желание узнать как эффективно решить задачу.

add: _Pasha, спасибо за тэги.

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

этот и другие замечательние языковые(не относящиеся к ООА и ООП) приёмы не плохо изложен в книге Джефа Элджера "C++". Чёрная такая обложечка. Если не смотрели - рекомендую почитать.

Как-то не очень понятно, почему разнокачественные вещи в одном списке: картофель, резать ромбиками, отварить. Я так понимаю, что элементы первого списка: картофель, морковь, огурец; элементы второго списка: резать кубиками, резать ромбиками, резать параллелепипедами; элементы третьего списка: жарить, варить, заморозить, запечь.

Если оно так, то всё получается достаточно логично.

Список1.добавить_элемент(картофель)
Список1.добавить_элемент(морковь)
Список1.добавить_элемент(огурец)

Список2_1.добавить_элемент(резать_кубиками)
Список2_2.добавить_элемент(резать_ромбиками)
Список2_3.добавить_элемент(резать_параллелепипедами)

Список2_1.добавить_элемент(резать_колёсиками)
Список2_2.добавить_элемент(резать_соломкой)
Список2_3.добавить_элемент(шинковать_колечками)


Список3_1.добавить_элемент(жарить)
Список3_1.добавить_элемент(варить)
Список3_1.добавить_элемент(парить)

Список3_2.добавить_элемент(морозить)
Список3_2.добавить_элемент(парить)
Список3_2.добавить_элемент(жарить)

картофель.назначить_цель(Список2_1)
морковь.назначить_цель(Список2_2)
огурец.назначить_цель(Список2_1)

Правда, тут я вот вижу уже нестыковку - линковать Список3 на элементы Списка2 как-то нелогично, а логично Список3 линковать на элементы, опять же, Списка1. Т.е. картофель->варить, а не резать_кубиками->варить. Т.е. тут над дизайном подумать надо. Но механизм связывания пунктов списков с их целями остаётся таким же. Как это делается по коду, приведено в предыдущем моём посте.



А где вы видите "свитч-кэйс" при обращении к базовом классу?


Что такое ВТД?

Так у меня также и написано в сообщении

Отобразилось неправильно на форуме, пробелы для выравнивания исчезли. Причем при редактировании всё выравнивание пробелами есть.

P.S. Вопрос к модераторам или администраторам: как правильно делать сообщение, чтобы введенные пробелы отображались корректно.

Я ни тот ни этот, но знаю: теги code и /code как раз на этот случай

конструкцию Вашего кода я в комментах оставил.

очепятался. имелось ввиду виртуальная таблица.

Да, я видел. Так где там "свитч-кэйс" при обращении к базовом классу? Конкретно код приведите, который имеете в виду? Где там базовый класс? Где к нему обращение? И базовый класс чего?

У меня вырисовывается следующая концепция.

Иерархия виджетов общепринятая. Здесь вопросов нет.

Но виджеты (как мне кажется) не могут существовать сами по себе (создаваться, исчезать), т.е. нужен некий оконный менджер, пусть и однопоточный.

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

В общем сейчас там одно окно отрисовывается, но это сделано "в лоб".

Хочется упорядоченности.

У меня появилась мысль. Окна все заранее конструируются (как, например в QT).

В классе виджета FDesktop есть "пул" на некоторое количество базовых виджетов, примерно так


В этом пуле хранятся адреса всех виджетов, которые создаются и уничтожаются в процессе работы (не принадлежат рабочему столу). Кнопки, часики, обои - это все принадлежит рабочему столу.

У рабочего стола вызывается метод его отриосвки desktop.draw() с некоторой периодичностью, который "смотрит" в пул, и если там есть указатели не на нулевые адреса "активных, под фокусом" виджетов, то вызывает их методы draw().

Если есть сообщение от именно клавиатуры, то оно приходит виджету под фокусом (тут вроде без исключений, т.к. пользователь работает с "текущим" окном всегда). Конечно, могут быть заранее заданные комбинации клавиш (типа CTRL + ALT +DEL во многих ОС), когда они перехватываются в данном случае "рабочем столом", а еще лучше вообще не передаются в графическую подсистему. В любом случае, виджеты на них не должны реагировать.

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

Вот, например, мой виджет FButton, в конструкторе принимает следующее


Пояснения, думаю, не требуются. Правильно ли, идеологически, в данном случае задавать реакцию при нажатию на кнопку таким образом (через указатель) на функцию? Вроде бы да. Ведь кнопка может быть нажата через тачскрин, выбрана кнопками "стрелками", или энкодером. И каждый раз проверять откуда пришло сообщение о нажатии на кнопку не совсем оптимально. Проще отработать некую функцию просто по нажатию на кнопку. Даже если на нее не нажимали, а установили ей ствойство pressed в true.

В общем как-то так, пока смутно...

И, нужно ли обнавлять виджеты, если они "прикрыты" в данный момент активным окном? Проще ведь отрисовывать виджет только под фокусом, и то, что ему принадлежит (т.е. дерево виджетов, начиная с родителя )?

Покопал коды Microchip Library, других библиотек. Но немного сложновато разобраться в их механизме...(


Спасибо!

Примерно так и делается. У меня тоже есть групповые объекты. Например, меню и прочие экранные списки содержат объект:

который содержит, как правило, указатели на виджеты, обрабатываемые в контексте их виджета-контейнера (меню, например).

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

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

Ну вот и замечательно, значит мой рассудок еще не сильно пострадал от поставленной задачи) Я, честно говоря, думал, что эта задача полегче будет. Но не совсем так, когда не используешь готовые библиотеки)



Да-да!!! В QT, насколько я помню, так тоже сделано (я с ней работал некоторое время). Там есть различные слои, на которых можно разместить и выровнять соответствующим образом, виджеты)

Спасибо!!!