Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Организация меню.
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Jenya7
У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?
iosifk
Цитата(Jenya7 @ Oct 25 2016, 13:37) *
У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?


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

Jenya7
Цитата(iosifk @ Oct 25 2016, 16:06) *
Я делаю так.
Вся управляющая программа должна быть описана как самый верхний автомат состояний. И каким-то состояниям этого автомата должны быть приписаны разные экраны.
В некоторых экранах есть "меню", которые тоже представляют собой автоматы состояний. И, соотв. каждому состоянию должно быть приписано условие отображения на этом экране. Нижние автоматы передают верхнему свое состояние или флаги.
Как только сделаете чтобы отображение соответствовало состоянию автомата, так все далее будет легко и просто...
Состояние главного автомата покажет, какой экран активный и в какой экран можно переходить, а в какой - нельзя. Соотв. нижний автомат покажет, какой пункт меню был нажат, какой выполнен, в какой можно переходить, а в какой - нельзя...

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

Мне нужно найти какую нибудь компактную форму хранения выбранных разделов. Не хочу создавать двойной массив.
iosifk
Цитата(Jenya7 @ Oct 25 2016, 14:11) *
Но должна же быть какая то глобальная структура хранящая состояния автомата. В принципе зная выбранный экран и выбранный раздел в нем я в свиче могу перебрать все кейсы и решить какое действие предпринять.

Мне нужно найти какую нибудь компактную форму хранения выбранных разделов. Не хочу создавать двойной массив.

Массив структур... Или классы состояний автомата.
В главном автомате - указатель на текущий.
Jenya7
а что если так
CODE
typedef struct SCREEN1_S
{
uint8_t item_idx;
}SCREEN1;

typedef struct SCREEN2_S
{
uint8_t item_idx;
}SCREEN2;

typedef struct SCREEN3_S
{
uint8_t item_idx;
}SCREEN3;

typedef struct SCREENS_S
{
SCREEN1 scr1;
SCREEN2 scr2;
SCREEN3 scr3;
}SCREENS;

нет. структура хранит выбранный раздел меню но из нее не видно какой экран выбран.

о. есть идея. можно немного модифицировать.
CODE

typedef struct SCREEN1_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN1;

typedef struct SCREEN2_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN2;

typedef struct SCREEN3_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN3;

typedef struct SCREENS_S
{
SCREEN1 scr1;
SCREEN2 scr2;
SCREEN3 scr3;
}SCREENS;

теперь есть индикация выбранного экрана.
iosifk
Цитата(Jenya7 @ Oct 25 2016, 14:26) *
а что если так
Код
typedef struct SCREEN1_S
{
  uint8_t item_idx;
}SCREEN1;

typedef struct SCREEN2_S
{
  uint8_t item_idx;
}SCREEN2;

typedef struct SCREEN3_S
{
  uint8_t item_idx;
}SCREEN3;

typedef struct SCREENS_S
{
  SCREEN1 scr1;
  SCREEN2 scr2;
  SCREEN3 scr3;
}SCREENS;


Ну просто беда с Вами...
Забудьте, что у Вас "экраны"... Вы же не картины в Эрмитаже рисуете. Любой Ваш "экран" - это набор примитивов графики, их координаты на экране, тексты и их координаты на экране и фон...
Соответственно, определите один "экран", т.е создайте его описание как массив или структуру или класс с этими графическими примитивами...
Потом соответственно, главный экран, соответствующий верхнему автомату будет содержать массив экранов и указатель на активный по состоянию главного автомата...
Jenya7
Цитата(iosifk @ Oct 25 2016, 16:35) *
Ну просто беда с Вами...
Забудьте, что у Вас "экраны"... Вы же не картины в Эрмитаже рисуете. Любой Ваш "экран" - это набор примитивов графики, их координаты на экране, тексты и их координаты на экране и фон...
Соответственно, определите один "экран", т.е создайте его описание как массив или структуру или класс с этими графическими примитивами...
Потом соответственно, главный экран, соответствующий верхнему автомату будет содержать массив экранов и указатель на активный по состоянию главного автомата...

У меня библиотека которая создает экраны. Каждый экран это набор графических элементов - кнопки, лейблы, чекбоксы, и.т.д Я могу вызвать экран и работать с графическими элементами - в моем случае это элементы типа LABEL - каждый LABEL это пункт меню. мне лишь нужно знать выбранный экран и пункт меню в нем.
iosifk
Цитата(Jenya7 @ Oct 25 2016, 14:45) *
У меня библиотека которая создает экраны. Каждый экран это набор графических элементов - кнопки, лейблы, чекбоксы, и.т.д Я могу вызвать экран и работать с графическими элементами - в моем случае это элементы типа LABEL - каждый LABEL это пункт меню. мне лишь нужно знать выбранный экран и пункт меню в нем.

Ну вот, значит прорисовывать экран не нужно. И все же - экран - это массив " элементы типа LABEL", и любое действие с этими элементами должно возвращать указатель на то, какой элемент был активен...
k155la3
Цитата(Jenya7 @ Oct 25 2016, 13:37) *
У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?


Можно - как вариант, для простых реализаций.
Основной элемент меню - консольный цикл. Нечто автомато-подобное sm.gif
Под ним подразумевается ввод оператором команд (Up-Down-Left-Right, Enter, Esc),
вывод информации на экран, режим редактирования.
В этот цикл встраивается прикладная часть, зависящая от конкретный задач в данном пункте меню.

Меню строится как обычные вызовы функций, тем самым легко обеспечивается "возвращаемость"
параметров и установок пунктов-разделов меню при выходе "вверх".

Недостаток - разрастается стек при большой вложенности.

Если требуется легко масштабируемое-изменяемое меню, то все "типовые" данные
(наименования пунктов, номерация, вызываемые ф-ии итп) заносятся в массив структур.
При этом сама функция, реализующая меню, будет проядка сотни строк, и ОДНА sm.gif
Вся прикладная функциональность прописывается в таблицу в виде констант, литералов,
указателей на прикладные функции-"обработчики".
Jenya7
Цитата(k155la3 @ Oct 25 2016, 17:49) *
Если требуется легко масштабируемое-изменяемое меню, то все "типовые" данные
(наименования пунктов, номерация, вызываемые ф-ии итп) заносятся в массив структур.
При этом сама функция, реализующая меню, будет проядка сотни строк, и ОДНА sm.gif
Вся прикладная функциональность прописывается в таблицу в виде констант, литералов,
указателей на прикладные функции-"обработчики".

мне даже не надо сохранять наименования пунктов и вызываемые функции. достаточно выбранный пункт.
_pv
Цитата(Jenya7 @ Oct 25 2016, 19:01) *
мне даже не надо сохранять наименования пунктов и вызываемые функции. достаточно выбранный пункт.

меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.
k155la3
Цитата(_pv @ Oct 25 2016, 18:26) *
меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.


В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?
Jenya7
Цитата(_pv @ Oct 25 2016, 21:26) *
меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.

это как?
Цитата(k155la3 @ Oct 26 2016, 12:25) *
В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?

это как?
XVR
Вам нужен стек, каждый элемент которого хранит номер экрана (или указатедь на экран) и номер (или указатель) текущего элемента в нем.
Тогда при вызове вложенного меню вы заталкиваете в стек текущее меню и текущий элемент в нем, а при закрытии меню извлекаете из стека верхний элемент и отрисовываете
_pv
Цитата(k155la3 @ Oct 26 2016, 13:25) *
В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?

У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.

Код
    typedef const struct Menu_Item {
        const struct Menu_Item *Next; /**< Pointer to the next menu item of this menu item */
        const struct Menu_Item *Previous; /**< Pointer to the previous menu item of this menu item */
        const struct Menu_Item *Parent; /**< Pointer to the parent menu item of this menu item */
        const struct Menu_Item *Child; /**< Pointer to the child menu item of this menu item */
        void (*SelectCallback)(void); /**< Pointer to the optional menu-specific select callback of this menu item */
        void (*EnterCallback)(void); /**< Pointer to the optional menu-specific enter callback of this menu item */
        const char Text[]; /**< Menu item text to pass to the menu display callback function */
    } Menu_Item_t;


https://github.com/abcminiuser/micromenu-v2
Jenya7
Цитата(_pv @ Oct 26 2016, 17:06) *
У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.

Код
    typedef const struct Menu_Item {
        const struct Menu_Item *Next; /**< Pointer to the next menu item of this menu item */
        const struct Menu_Item *Previous; /**< Pointer to the previous menu item of this menu item */
        const struct Menu_Item *Parent; /**< Pointer to the parent menu item of this menu item */
        const struct Menu_Item *Child; /**< Pointer to the child menu item of this menu item */
        void (*SelectCallback)(void); /**< Pointer to the optional menu-specific select callback of this menu item */
        void (*EnterCallback)(void); /**< Pointer to the optional menu-specific enter callback of this menu item */
        const char Text[]; /**< Menu item text to pass to the menu display callback function */
    } Menu_Item_t;


https://github.com/abcminiuser/micromenu-v2

спасибо.попробую. я правда не понимаю - у меня относительно простое меню, три экрана по три пункта в экране - 9 пунктов. можно ведь пробежаться по ним в одном кейсе. зная выбранный пункт передать его в свич и все дела. или я что то не понимаю.
k155la3
Цитата(_pv @ Oct 26 2016, 14:06) *
У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.
. . . .
https://github.com/abcminiuser/micromenu-v2

Спасибо.
Ссылка правильная sm.gif
Цитата(Jenya7 @ Oct 27 2016, 08:56) *
спасибо.попробую. я правда не понимаю - у меня относительно простое меню, три экрана по три пункта в экране - 9 пунктов. можно ведь пробежаться по ним в одном кейсе. зная выбранный пункт передать его в свич и все дела. или я что то не понимаю.

Все просто.
-------
(1) Если это разовая (учебная) задача - делайте как удобно, как Вам будет понятно и логично.
(в надежде, что исходя из этого будет правильно и надежно. Но не факт)
При этом при каждом изменении- дополнении - удалнении Вам придется вспоминать что Вы напрограммировали,
читать комментарии, вникать, что было, например года полтора назад sm.gif
В процессе набивания шишек по (1) Вы перейдете к (2) sm.gif
------
(2) Если это постоянная, серьезная разработка - надо все формализовать, чтобы добавление пункта меню
было добавлением строки параметров в таблице и указанием в ней функции-обработчика(ов),
а не "исследования" по (1) с правкой кода и прочей канителью.
Кроме того формализация автом. обеспечивает минимизацию логических ошибок.
-----
по "непониманию"
----------
Для начала реализуйте на case-swith - у Вас все получится.
Потом представьте, что Ваше меню состоит из десятка уровней и до сотни пунктов в некоторых входах.
Jenya7
понял. спасибо.
uriy
Я тоже в нескольких проектах применял micromenu. Рекомендую!
Jenya7
Цитата(uriy @ Oct 28 2016, 12:00) *
Я тоже в нескольких проектах применял micromenu. Рекомендую!

спасибо. остановлюсь на нем.
Jenya7
портирую micromenu в проект и там есть такой дифайн
Код
#define MENU_ITEM_STORAGE  PROGMEM

#define MENU_ITEM(Name, Next, Previous, Parent, Child, SelectFunc, EnterFunc, Text) \
              extern Menu_Item_t MENU_ITEM_STORAGE Next;     \
    extern Menu_Item_t MENU_ITEM_STORAGE Previous; \
    extern Menu_Item_t MENU_ITEM_STORAGE Parent;   \
    extern Menu_Item_t MENU_ITEM_STORAGE Child;  \
    Menu_Item_t MENU_ITEM_STORAGE Name = {&Next, &Previous, &Parent, &Child, SelectFunc, EnterFunc, Text}

но PROGMEM (размещение во флэш ) это для AVR а для кортекса что будет? что то я туплю.

сделал так.
Код
#define MENU_ITEM_STORAGE  const


вобще то размер RAM позволяет хранить меню в RAM. обязательно пихать его во флэш?
k155la3
Цитата(Jenya7 @ Nov 3 2016, 09:52) *
. . . . .
вобще то размер RAM позволяет хранить меню в RAM. обязательно пихать его во флэш?


Распологать во флеш следует все данные, которые не будут изменяться во время выполнения Вашего кода,
а также те, которые определены на этапе компиляции.
Если вы делаете обычное меню, а не динамически настраиваемое (не знаю зачем это комуто может понадобиться)
то используйте флеш.
Jenya7
Цитата(k155la3 @ Nov 3 2016, 14:25) *
Распологать во флеш следует все данные, которые не будут изменяться во время выполнения Вашего кода,
а также те, которые определены на этапе компиляции.
Если вы делаете обычное меню, а не динамически настраиваемое (не знаю зачем это комуто может понадобиться)
то используйте флеш.

понял. спасибо.
Jenya7
кто нибудь портировал под ARM это меню? начинает бесить.
k155la3
Цитата(Jenya7 @ Nov 3 2016, 12:59) *
кто нибудь портировал под ARM это меню? начинает бесить.

Вы не старайтесь "в лоб" перегнать код под свой target.
Это может быть контрпродуктивно sm.gif
Разберитесь детально в логике работы и реализуйте на своем процессоре.


Jenya7
Цитата(k155la3 @ Nov 3 2016, 16:07) *
Вы не старайтесь "в лоб" перегнать код под свой target.
Это может быть контрпродуктивно sm.gif
Разберитесь детально в логике работы и реализуйте на своем процессоре.

так то и бесит что структуры не привязанные к платформе не работают. в принципе тут все должно быть генерик.
_pv
Цитата(Jenya7 @ Nov 3 2016, 17:37) *
так то и бесит что структуры не привязанные к платформе не работают. в принципе тут все должно быть генерик.

чему там не работать-то?
там из платформозависимого только два макроса
#define MENU_ITEM_STORAGE PROGMEM
#define MENU_ITEM_READ_POINTER(Addr) (void*)pgm_read_word(Addr)

первый можно заменить на const, или на ничего если памяти не жалко,
второй на ((void*)(Addr)), так как это у авр указатели на флэш и обычные указатели отличаются.

ну либо, как уже сказали, просто посмотреть как сделано и сделать самому без заворачивания в макросы и кастования void*.
Jenya7
Цитата(_pv @ Nov 3 2016, 22:50) *
чему там не работать-то?
там из платформозависимого только два макроса
#define MENU_ITEM_STORAGE PROGMEM
#define MENU_ITEM_READ_POINTER(Addr) (void*)pgm_read_word(Addr)

первый можно заменить на const, или на ничего если памяти не жалко,
второй на ((void*)(Addr)), так как это у авр указатели на флэш и обычные указатели отличаются.

ну либо, как уже сказали, просто посмотреть как сделано и сделать самому без заворачивания в макросы и кастования void*.

а почему (void*)? (Menu_item_t*) вроде как.
_pv
Цитата(Jenya7 @ Nov 4 2016, 16:34) *
а почему (void*)? (Menu_item_t*) вроде как.

наследие АВР, при хранении меню во флэше pgm_read_ возвращает void*.
соответственно указатели на колбэки и на другие пункты меню читаются из флэша как void* и где надо приводятся к (Menu_item_t*), а где надо к void (*Callback)(void).
то есть там вообще что угодно может быть и всё равно где надо приведётся к нужному типу.
#define MENU_ITEM_READ_POINTER(Addr) (Addr)
работать будет ничуть не хуже.
Jenya7
Цитата(_pv @ Nov 4 2016, 17:16) *
наследие АВР, при хранении меню во флэше pgm_read_ возвращает void*.
соответственно указатели на колбэки и на другие пункты меню читаются из флэша как void* и где надо приводятся к (Menu_item_t*), а где надо к void (*Callback)(void).
то есть там вообще что угодно может быть и всё равно где надо приведётся к нужному типу.
#define MENU_ITEM_READ_POINTER(Addr) (Addr)
работать будет ничуть не хуже.

я понял. спасибо.
чтоб не открывать отдельную тему хочу спросить. по сути дела это Linked List. Каждый член структуры имеет тип этой структуры, ну кроме указателей на функции. но такого типа в принципе нет, есть uint8_t, uint32_t , но Menu_item_t это наше определение. так сколько байт займет структура после компиляции?
_pv
Цитата(Jenya7 @ Nov 4 2016, 17:50) *
я понял. спасибо.
чтоб не открывать отдельную тему хочу спросить. по сути дела это Linked List. Каждый член структуры имеет тип этой структуры, ну кроме указателей на функции. но такого типа в принципе нет, есть uint8_t, uint32_t , но Menu_item_t это наше определение. так сколько байт займет структура после компиляции?

6 указателей по 4 (для кортекса) байта.
Jenya7
Цитата(_pv @ Nov 4 2016, 18:38) *
6 указателей по 4 (для кортекса) байта.

спасибо.
Jenya7
Вобщем прикрутил таки
https://github.com/abcminiuser/micromenu-v2
Оч доволен. Навигация по пунктам меню, с колбэками, все работает четко. Но пункты дбавляю в дизайн тайм
Код
//MAIN MENU
//            NAME      NEXT,       PREVIOUS    PARENT,      CHILD       //SELECT    //ENTER
MENU_ITEM(m_manual, m_fails,    m_auto,       NULL_MENU,   NULL_MENU,  NULL_FUNC,   NULL_FUNC,  "MANUAL");
MENU_ITEM(m_fails,  m_muxbus,   m_manual,   NULL_MENU,   m_mf,       NULL_FUNC,   GoToChild,  "FAILS ");
MENU_ITEM(m_maint,  m_auto,     m_muxbus,   NULL_MENU,   m_lmfls,    NULL_FUNC,   GoToChild,  "MAINT ");
MENU_ITEM(m_auto,   m_manual,   m_maint,    NULL_MENU,   NULL_MENU,  NULL_FUNC,   NULL_FUNC,  "AUTO  ");
Но я как всегда со своими идеями - а что если добавлять пункты в ран тайм
Код
void MenuItemCreate (Menu_Item_t Name, Menu_Item_t Next)
{
    MENU_ITEM(Name, Next, NULL_MENU, NULL_MENU, NULL_MENU, NULL_FUNC, NULL_FUNC, "TEST");
}
Компайлер конечно орет - он хочет extern. а я не могу передать extern в функцию.
Можно как то схитрожопить?
inventor
я взял за образец меню от миландра
перетащил на свой контроллер и другой дисплей
все работает.
Jenya7
Цитата(inventor @ Sep 6 2018, 20:59) *
я взял за образец меню от миландра
перетащил на свой контроллер и другой дисплей
все работает.


спасибо. очень даже интересная идея.
x893
Если не секрет - Какая идея очень даже интересная ?
Jenya7
Цитата(x893 @ Sep 7 2018, 13:00) *
Если не секрет - Какая идея очень даже интересная ?


Код
void ReadKey(void)
{
    uint32_t key;

    while (1) {
    key = GetKey();
    switch (key) {
    case SEL:
        SelFunc();
        break;
    case UP:
        UpFunc();
        break;
    case DOWN:
        DownFunc();
        break;
    case BACK:
        ReturnFunc();
        break;
    }
    WAIT_UNTIL_KEY_RELEASED(key);
    }
}
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.