Динамическое меню
- Войдите на сайт для отправки комментариев
Пт, 23/10/2020 - 12:17
Доброго для, господа! Пытаюсь сделать древовидное меню, подпункты которого меняются в процессе работы. Например, в начальном пункте меню(родительском) есть два пункта:
1. Тип объекта
2.Свойства объекта
В зависимости от типа объекта список его свойств меняется.
например:
тип объекта - куб,
его свойства - цвет, масса, длина грани x.
тип объекта - шар,
его свойства - цвет, масса, радиус.
Делал через структуру, содержащую имя родителя, собственное имя, название для отображения, переменную и тип(папка это или файл).
Потом в процессе работы по родителю собирал все в массив через realloc. Все вроде работало, но динамический массив иногда глючил. При описании структуры на больное колличество элементов(н/р 5 родителей, у каждого 5 детей, у каждого по паре свойств) начинало занимать очень много памяти и не оставалось кода для основной программы.
В основном коде программы работа идет только с одним, ранее выбранным объектом. Поэтому хотелось бы повторяющиеся свойства использовать для всех объектов, у кого они есть, фактически иметь одну переменную.
Подскажите, пожалуйста, в какую сторону думать? На верном ли я пути?
Опубликуйте структуру и выделите там типы свойств, которые требуется повторно использовать.
При описании структуры на больное колличество элементов(н/р 5 родителей, у каждого 5 детей, у каждого по паре свойств) начинало занимать очень много памяти и не оставалось кода для основной программы.
Ну допустим свойство 20 байт. Тогда 20 * 2 * 5 * 5 + указатели 2 * 5 * 5 = 1000 + 50, и в правду многовато будет для уно. Но если тебе эта информация нужна, то ты с этим ничего не поделаешь. Придется брать контроллер пожирнее.
В основном коде программы работа идет только с одним, ранее выбранным объектом. Поэтому хотелось бы повторяющиеся свойства использовать для всех объектов, у кого они есть, фактически иметь одну переменную.
Что бы это могло значить?
Что бы это могло значить?
Это к примеру выше. Если в типе объекта мы выбрали куб, то с доступными к выбору шаром, треугольником и .т.д. работа в основном коде проводится не будет. А свойство н.р. цвет будет для всех из одной переменной.
Если у тебя все объекты одного цвета, то конечно же не нужно к каждому отдельному объекту прикладывать свою переменную.
Опубликуйте структуру и выделите там типы свойств, которые требуется повторно использовать.
с повторениями ясно. А сам принцип реализации меню только динамическим может быть в моем случае? Может есть менее ресурсозатратные варианты?
А сам принцип реализации меню только динамическим может быть в моем случае? Может есть менее ресурсозатратные варианты?
вообще-то динамический - самый экономный по ресурсам из всех, статические еще хуже
А сам принцип реализации меню только динамическим может быть в моем случае? Может есть менее ресурсозатратные варианты?
вообще-то динамический - самый экономный по ресурсам из всех, статические еще хуже
Вообще-то наоборот.
Вообще-то наоборот.
ну это смотря как использовать. Если заранее выделять ресурсы под все элементы - то конечно статика экономней динамики, но в таком разе в динамике и смысла никакого.
А если динамически выделять ресурс только под текущий элемент, потом освобождать и выделять под следующий - то динамика выгоднее
Тут вопрос в том. как у ТС организована программа, можно ли использовать динамический метод или он в начале тупо выделяет всю необходимую память
А в перерывах где элемент хранится?
Мне кажется, главное - тщательно продумать структуру записей.
Посмотрите, может, что-то окажется полезным http://arduino.ru/forum/proekty/menyu-dlya-dvukhstrochnogo-displeya
https://youtu.be/PyOdQMH7JxU
Вообще-то наоборот.
ну это смотря как использовать. Если заранее выделять ресурсы под все элементы - то конечно статика экономней динамики, но в таком разе в динамике и смысла никакого.
А если динамически выделять ресурс только под текущий элемент, потом освобождать и выделять под следующий - то динамика выгоднее
Тут вопрос в том. как у ТС организована программа, можно ли использовать динамический метод или он в начале тупо выделяет всю необходимую память
Создаю массив элементов пункта меню на который перехожу. Т.е. в единицу времени создан только один массив, но разного размера.
Вот это и есть ваши затраты на динамику. Если в системе нет СД карты, то придется городить ее аналог в PROGMEM . Придумать структуру данных разных типов. А потом в виде данных структуры организовывать PROGMEM массивы. Вот это и есть ваш меню-ландшафт который вы будете менять и тестировать вручную.
ПС: Можно городить меню-ландшафт и в EEPROM, но здесь тоже жопа. Надо загрузить изначальный из коробки, который теперь надо вызывать ,правильно, PROGMEM-а.
Думаю вывод понятен. Если нечего делать, то копайте огород.Тогда хоть мускулы будут или мозоли если первый раз.
"Элементы пункта меню" - это что значит? Пункт меню это и есть элемент меню. И никакие массивы выделять не надо. Есть буфер экрана, код его заполняет в зависимости от ввода пользователя и состояния системы. Всё.
"Элементы пункта меню" - это что значит? Пункт меню это и есть элемент меню. И никакие массивы выделять не надо. Есть буфер экрана, код его заполняет в зависимости от ввода пользователя и состояния системы. Всё.
Извиняюсь, выразился не корректно. Я имел ввиду пункт меню, тот что содержит другие пункты, что являются его потомками. Название папки - родитель, файлы в папке - динамично созданный массив.
И после того как ты вышел из папки — файлы удаляются? Какой смысл в такой папке? Чего за бредовые идеи
И после того как ты вышел из папки — файлы удаляются? Какой смысл в такой папке? Чего за бредовые идеи
"Файлы" не удаляются, удаляется массив, который объединял файлы с одним родителем и создается новый с родителем текущим.
И зачем нужен еще один массив? И даже если ты решил что нужен, зачем его выделять динамически каждый раз?
И зачем нужен еще один массив? И даже если ты решил что нужен, зачем его выделять динамически каждый раз?
Так массив всего один. Изначально все пункты меню описаны в структуре определенного формата. А в процессе работы из них выбирается пункты с общим родителем и собираются в массив.
Я не утверждаю что так делать нужно. Для этого и написал на форум, что бы спросить как правильнее делаются такие вещи.
У Вас где то должна быть описана структура меню. Без этой информации невозможно строить необходимые в данный момент пункты меню. Какой смысл эту информацию перекидывать в динамический массив? Это же удвоение и лишнее телодвижение? Почему просто не передавать ссылки на структуры описания?
Ваш вопрос звучит примерно так: Я делаю то-то и то-то, правильно ли я делаю?
Но на этот вопрос невозможно ответить, не зная, чего Вы хотите добиться.
А это из Ваших объяснений совершенно непонятно.
Если Вы храните основу меню в PROGMEM, то непонятно, зачем копировать ее в ОЗУ. Если Вы в ОЗУ делаете некоторые изменения, а потом, при входе в другой пункт меню, пересоздаете массив заново, значит, Вы теряете информацию об изменениях. Непонятно, зачем нужны такие манипуляции. Чего Вы хотите добиться?
ПС: И начинать начинающие меню-стороители должны с изучения енумов. https://ravesli.com/urok-58-perechisleniya-tip-enum/