Цитата(dxp @ Sep 14 2012, 10:14) 
...А где вы видите "свитч-кэйс" при обращении к базовом классу?..Что такое ВТД?
конструкцию Вашего кода я в комментах оставил.
очепятался. имелось ввиду виртуальная таблица.
Полная версия этой страницы: Embedded GUI
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
конструкцию Вашего кода я в комментах оставил.
очепятался. имелось ввиду виртуальная таблица.
QUOTE (kolobok0 @ Sep 14 2012, 17:47)
конструкцию Вашего кода я в комментах оставил.
Да, я видел. Так где там "свитч-кэйс" при обращении к базовом классу? Конкретно код приведите, который имеете в виду? Где там базовый класс? Где к нему обращение? И базовый класс чего?
У меня вырисовывается следующая концепция.
Иерархия виджетов общепринятая. Здесь вопросов нет.
Но виджеты (как мне кажется) не могут существовать сами по себе (создаваться, исчезать), т.е. нужен некий оконный менджер, пусть и однопоточный.
У меня это некий виджет, унаследованный от базового FDesktop, который на эране отрисовывает фоновую картинку, кнопочки по бокам экрана (там есть физические кнопки, тачскрин не приклеен) Тут как это примерно выглядит.( На звук не обращайте внимание. Забыл телевизор выключить.)
В общем сейчас там одно окно отрисовывается, но это сделано "в лоб".
Хочется упорядоченности.
У меня появилась мысль. Окна все заранее конструируются (как, например в QT).
В классе виджета FDesktop есть "пул" на некоторое количество базовых виджетов, примерно так
В этом пуле хранятся адреса всех виджетов, которые создаются и уничтожаются в процессе работы (не принадлежат рабочему столу). Кнопки, часики, обои - это все принадлежит рабочему столу.
У рабочего стола вызывается метод его отриосвки desktop.draw() с некоторой периодичностью, который "смотрит" в пул, и если там есть указатели не на нулевые адреса "активных, под фокусом" виджетов, то вызывает их методы draw().
Если есть сообщение от именно клавиатуры, то оно приходит виджету под фокусом (тут вроде без исключений, т.к. пользователь работает с "текущим" окном всегда). Конечно, могут быть заранее заданные комбинации клавиш (типа CTRL + ALT +DEL во многих ОС), когда они перехватываются в данном случае "рабочем столом", а еще лучше вообще не передаются в графическую подсистему. В любом случае, виджеты на них не должны реагировать.
В общем у меня пока плохо укладывается идея управления окнами. Как их создавать, удалять, обновлять и т.п.
Вот, например, мой виджет FButton, в конструкторе принимает следующее
Пояснения, думаю, не требуются. Правильно ли, идеологически, в данном случае задавать реакцию при нажатию на кнопку таким образом (через указатель) на функцию? Вроде бы да. Ведь кнопка может быть нажата через тачскрин, выбрана кнопками "стрелками", или энкодером. И каждый раз проверять откуда пришло сообщение о нажатии на кнопку не совсем оптимально. Проще отработать некую функцию просто по нажатию на кнопку. Даже если на нее не нажимали, а установили ей ствойство pressed в true.
В общем как-то так, пока смутно...
И, нужно ли обнавлять виджеты, если они "прикрыты" в данный момент активным окном? Проще ведь отрисовывать виджет только под фокусом, и то, что ему принадлежит (т.е. дерево виджетов, начиная с родителя )?
Покопал коды Microchip Library, других библиотек. Но немного сложновато разобраться в их механизме...(
Спасибо!
Иерархия виджетов общепринятая. Здесь вопросов нет.
Но виджеты (как мне кажется) не могут существовать сами по себе (создаваться, исчезать), т.е. нужен некий оконный менджер, пусть и однопоточный.
У меня это некий виджет, унаследованный от базового FDesktop, который на эране отрисовывает фоновую картинку, кнопочки по бокам экрана (там есть физические кнопки, тачскрин не приклеен) Тут как это примерно выглядит.( На звук не обращайте внимание. Забыл телевизор выключить.)
В общем сейчас там одно окно отрисовывается, но это сделано "в лоб".
Хочется упорядоченности.
У меня появилась мысль. Окна все заранее конструируются (как, например в QT).
В классе виджета FDesktop есть "пул" на некоторое количество базовых виджетов, примерно так
CODE
class FDesktop : private FWidget, ....
{
public:
...
private:
FWidget* widgetPool[ 100 ];
};
{
public:
...
private:
FWidget* widgetPool[ 100 ];
};
В этом пуле хранятся адреса всех виджетов, которые создаются и уничтожаются в процессе работы (не принадлежат рабочему столу). Кнопки, часики, обои - это все принадлежит рабочему столу.
У рабочего стола вызывается метод его отриосвки desktop.draw() с некоторой периодичностью, который "смотрит" в пул, и если там есть указатели не на нулевые адреса "активных, под фокусом" виджетов, то вызывает их методы draw().
Если есть сообщение от именно клавиатуры, то оно приходит виджету под фокусом (тут вроде без исключений, т.к. пользователь работает с "текущим" окном всегда). Конечно, могут быть заранее заданные комбинации клавиш (типа CTRL + ALT +DEL во многих ОС), когда они перехватываются в данном случае "рабочем столом", а еще лучше вообще не передаются в графическую подсистему. В любом случае, виджеты на них не должны реагировать.
В общем у меня пока плохо укладывается идея управления окнами. Как их создавать, удалять, обновлять и т.п.
Вот, например, мой виджет FButton, в конструкторе принимает следующее
CODE
FButton( FPoint, uint32_t width, uint32_t height, void* callbackFunc );
Пояснения, думаю, не требуются. Правильно ли, идеологически, в данном случае задавать реакцию при нажатию на кнопку таким образом (через указатель) на функцию? Вроде бы да. Ведь кнопка может быть нажата через тачскрин, выбрана кнопками "стрелками", или энкодером. И каждый раз проверять откуда пришло сообщение о нажатии на кнопку не совсем оптимально. Проще отработать некую функцию просто по нажатию на кнопку. Даже если на нее не нажимали, а установили ей ствойство pressed в true.
В общем как-то так, пока смутно...
И, нужно ли обнавлять виджеты, если они "прикрыты" в данный момент активным окном? Проще ведь отрисовывать виджет только под фокусом, и то, что ему принадлежит (т.е. дерево виджетов, начиная с родителя )?
Покопал коды Microchip Library, других библиотек. Но немного сложновато разобраться в их механизме...(
Спасибо!
QUOTE (haker_fox @ Oct 3 2012, 12:58)
У меня вырисовывается следующая концепция.
...
...
Примерно так и делается. У меня тоже есть групповые объекты. Например, меню и прочие экранные списки содержат объект:
CODE
template<typename T> class group
{
public:
group(uint_fast8_t N)
: CurrIndex(0)
, Count(0)
, MaxCount(N)
{
Items = new T[N];
for(uint_fast16_t i = 0; i < N; ++i)
{
Items[i] = 0;
}
}
void draw();
void next();
void prev();
uint_fast16_t curr_index() const { return CurrIndex; }
uint_fast16_t count() const { return Count; }
void init(const uint_fast16_t index = 0) { CurrIndex = index; Items[index]->set_selected(true); }
void append(T item) { if(Count < MaxCount) Items[Count++] = item; else print("error: cannot append item to the group - the group is full\r\n"); }
void remove() { if(Count) { Items[Count-1] = 0; --Count; } else print("warning: cannot remove item - the group is empty\r\n"); }
void remove_all() { for(uint_fast8_t i = 0; i < Count; ++i) Items[i] = 0; Count = 0; }
T & operator[](uint_fast16_t index) { return Items[index]; }
T & curr_item() { return Items[CurrIndex]; }
private:
uint_fast16_t CurrIndex;
uint_fast16_t Count;
const uint_fast16_t MaxCount;
T *Items;
};
который содержит, как правило, указатели на виджеты, обрабатываемые в контексте их виджета-контейнера (меню, например).
Виджет окна тоже имеет подобный вашему массив указателей (только у меня он называется иначе
). В общем, эти детали реализации уже не являются ключевыми - тут по делается по здравому смыслу в контексте задачи и возможностей.
Хочу сказать, что тот, кто писал под ТурбоВижн, в любое время дня и ночи скажет, что без группового виджета а-ля TGroup, который только является владельцем нескольких отображаемых элементов и маршрутизирует события, - никак не обойтись. И это не штампы. Просто правильная сразу концепция.
QUOTE (dxp @ Oct 4 2012, 13:28)
Примерно так и делается. У меня тоже есть групповые объекты. Например, меню и прочие экранные списки содержат объект:
который содержит, как правило, указатели на виджеты, обрабатываемые в контексте их виджета-контейнера (меню, например).
Виджет окна тоже имеет подобный вашему массив указателей (только у меня он называется иначе). В общем, эти детали реализации уже не являются ключевыми - тут по делается по здравому смыслу в контексте задачи и возможностей.
который содержит, как правило, указатели на виджеты, обрабатываемые в контексте их виджета-контейнера (меню, например).
Виджет окна тоже имеет подобный вашему массив указателей (только у меня он называется иначе
). В общем, эти детали реализации уже не являются ключевыми - тут по делается по здравому смыслу в контексте задачи и возможностей.Ну вот и замечательно, значит мой рассудок еще не сильно пострадал от поставленной задачи) Я, честно говоря, думал, что эта задача полегче будет. Но не совсем так, когда не используешь готовые библиотеки)
QUOTE (_Pasha @ Oct 4 2012, 13:55)
Хочу сказать, что тот, кто писал под ТурбоВижн, в любое время дня и ночи скажет, что без группового виджета а-ля TGroup, который только является владельцем нескольких отображаемых элементов и маршрутизирует события, - никак не обойтись. И это не штампы. Просто правильная сразу концепция.
Да-да!!! В QT, насколько я помню, так тоже сделано (я с ней работал некоторое время). Там есть различные слои, на которых можно разместить и выровнять соответствующим образом, виджеты)
Спасибо!!!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.