Старая, но актуальная тема хранения настроек

Работа с файлами и базами данных
Ответить
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

Уважаемые господа!
Всю сознательную жизнь ))) существует тема хранения настроек. Я последнее время ее решал через хранение кластера в строке, с полем "Версия", идущим первым. Процессе жизненного цикла приложения всегда возникает необходимость изменения структуры настроек. Надо что-то добавить или что-то становится ненужным. Код в поле версии решает эти проблемы: прочитав его, ты знаешь к какому типу приводить строку последующих данных. Таким образом можно обеспечить хорошую совместимость вверх и иногда вниз (если соблюдать правило только добавлять поля). Все это замечательно, но такая структура обладает неприятным неудобством - файл с настройками затруднительно редактировать вне приложения.
Последнее время стало модным использовать XML файл в качестве хранения настроек. Да, его можно редактировать вручную, его структура создается автоматически. Но есть один серьезный момент, который лично мне мешает в приложениях его использовать: любое незначительное изменение структуры данных, даже такое, как добавление строки в RING структуру, приводит к абсолютной нечитаемости файла настроек штатным парсером. Хотя в аналогичной ситуации функция "Unflatten from String" прекрасно с этим справляется. Я пока не нашел способа безгеморойного определения даже номера версии записанной таким образом настроек. На этом фоне прописывание настроек через ini файл или реестр - щелканье семечек.
Может, кто-то может подсказать, как простыми средствами обеспечить совместимость вверх настроек, записанных в XML формате?
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: Старая, но актуальная тема хранения настроек

Сообщение Kosist »

Да, тема настроек - это наболевшее )) Я тоже ее здесь поднимал, но нормального решения пока не нашел.
Хотя насчет XML файлов есть соображения (правда, способ этот не совсем и простой, наверное). Смысл в том, что у нас есть кластер, который записывается в файл, и xml файл. Считывается xml файл при помощи Unflatten From XML Function, к которой, собственно, и подключается константа кластера, который записывался в этот файл. И когда xml файл меняется, то эта константа "не канает", и файл не будет прочитан. Вы это все тоже знаете, это я для введения.
И вот здесь можна сделать следующее. Из xml файла "вытянуть" строку в чистом виде. Распарсить ее, и достать все значения всех элементов. Паралельно, достать из кластера, в который нужно записать значения, параметры контролов (скажем, имена, иерархию, и т.д.). А потом сравнивать эти значения - имена контролов (иерархию и тип данных), записанных в файле, и находящихся в кластере, в который данные записываются. При совпадении параметров - данные считываются и записываются в кластер, если же нет - то ничего не пишется.
Плюсом тогда будет то, что при добавлении в файл "вручную" данных; или же изменении кластера, в который данные будут считываться, дефолтные значения "старых" контролов будут все равно прочитаны из файла, и забиты в кластер. И не нужно будет перебивать их вручную, "с нуля".
Мы делили апельсин - много наших полегло...
Аватара пользователя
Andrew Lunev

Activity Professionalism
VIP
VIP
Сообщения: 957
Зарегистрирован: 11 дек 2010, 12:31
Награды: 2
Версия LabVIEW: 2014-2021
Откуда: Москва
Благодарил (а): 4 раза
Поблагодарили: 10 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Andrew Lunev »

Я делаю проще. Сначала читается версия стандартными функциями из палитры XML, потом по номеру версии выбирается кластер соответствующей версии для расшифровки данных.
Пример определения версии:
Вложения
XML.png
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

Это и так понятно... Для того, чтобы не заниматься изобретанием велосипеда, мне достаточно знать тип записи и ее я уже могу без расшивания распознать, просто подставив соответствующий известный мне тип кластера. Изменил параметры - изменил значение версии и порядок. Сейчас покопал поглубже и вроде нашел удовлетворительное решение... Иначе никак не удается считать последовательно несколько структур.
Вложения
Настройки в XML.PNG
Stkn
assistant
assistant
Сообщения: 128
Зарегистрирован: 25 янв 2009, 11:08
Версия LabVIEW: 2014

Re: Старая, но актуальная тема хранения настроек

Сообщение Stkn »

Если использование XML не принципиально, то я обратил внимания на Read/Write Anything из библиотеки MGI http://mooregoodideas.com/readwrite-anything-vis/ или на ini с помощью OpenG.
Для XML у MGI тоже есть решение, но мне оно показалось сырым http://mooregoodideas.com/robustxml/.
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

Stkn, Спасибо, присмотрюсь
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5462
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 28 раз
Поблагодарили: 86 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение IvanLis »

Никогда не заморачивался по этому поводу, но можно имея несколько исходных вариантов структур, при открытии (Unflatten From XML Function) делать перебор всех возможных. Т.е. в случае возникновения ошибки, пробовать следующую и так пока не совпадет :crazy: .
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

IvanLis, Тут можно налететь, если по каким-то причинам структура данных одной версии "прокатывает" для другой.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5462
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 28 раз
Поблагодарили: 86 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение IvanLis »

Borjomy_1 писал(а):IvanLis, Тут можно налететь, если по каким-то причинам структура данных одной версии "прокатывает" для другой.
Значит это одинаковые структуры :wink: .
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

IvanLis, В общем случае - необязательно. Не знаю, насколько чувствителен парсер XML, однако Unflatten from String допускает вольности в интерпретации и нет оснований расчитывать на полную проверку парсером. Если версия структуры не будет должным образом указана, всегда можно налететь. И потом вылавливать ошибки по всей стране не очень хочется. При переходе на новую версию и так много проблем возникает, чтобы еще эту часть на авось отпускать.
AndreyDmitriev

Activity Professionalism Tutorials Gold Black
VIP
VIP
Сообщения: 1327
Зарегистрирован: 03 фев 2010, 00:42
Награды: 6
Версия LabVIEW: 6.1 - 2024
Откуда: Германия
Благодарил (а): 1 раз
Поблагодарили: 38 раз
Контактная информация:

Re: Старая, но актуальная тема хранения настроек

Сообщение AndreyDmitriev »

Borjomy_1 писал(а):IvanLis, В общем случае - необязательно. Не знаю, насколько чувствителен парсер XML, однако Unflatten from String допускает вольности в интерпретации и нет оснований расчитывать на полную проверку парсером.
О да, это так. Я однажды много лет назад ещё в версии 6 крепко получил по лбу граблями в попытке "определения версии" настроек, состоящих из массива кластеров. Грубо говоря, там в одном месте исходя из размера бинарного файла версия определялась, ну и три элемента по 30 байт могут ведь занимать столько же места, сколько и шесть по пятнадцать. Больше так не делаю.

Если серъёзно, то мне вот чисто субъективно XML не очень нравится для хранения настроек и "классические" ini файлы привычнее, что ли.
Я использую OpenG инструменты. Там в Variant Configuration File есть всё, что нужно.
У меня программа модульная и каждый модуль имеет свои собственные настройки. Соответственно, в каждом модуле есть инструмент <ModuleName>_Settings.vi. Кроме того, в каждом модуле есть Typedef <ModuleName>_Settings.ctl. <ModuleName>_Settings.vi одновременно представляет собой интерфейс пользователя для редактирования настроек. Я во-первых, не очень люблю нативные лабвьюшные кластеры пользователю показывать, а во-вторых, в настройках может потребоваться нехитрая логика (ну, типа, если какой-то чекбокс сняли, то часть настроек стала неактивна, и т.д.). Теперь ядро при старте ищет в каждом модуле <ModuleName>_Settings.vi, затем получает ссылки на каждый контрол на панели, Через стандартный Open Config Data открывает <ModuleName>_Settings.ini, отдаёт ссылки на панель и файл в OpenG. Ну а тулкит сам расставляет все значения в контролы. Если ini файл отсутствует, то у контролов остаются значения по умолчанию. То же самое происходит, если я добавляю новый контрол. Сохранение работате примерно таким же образом - все значения контролов через референсы собираются тулкитом и сбрасываются в ini. Ядро имеет один корневой инструмент, на котором в списке есть все установленные модули, а в SubPanel вставляется тот самый <ModuleName>_Settings.vi. Есть кнопка Default, которая всегда позволяет вернуть настройки в "как было". С точки зрения пользователя настройки точно также выглядят, как настройки в LabVIEW. Выход у каждого <ModuleName>_Settings.vi - вариант, в который перебрасывается <ModuleName>_Settings.ctl - это даёт возможность вызывать инструменты настроек динамически.
Теперь если мне надо добавить настройки в какой-либо модуль, то всё, что надо сделать - это бросить новый контрол на панель, добавить его в кластер typedef, ну и соединить контрол с элементом кластера, и это всё. Остальное берёт на себя ядро (включая перевод на другие языки). Где-то так. На XML (или даже в реестр) это дело перевести особых проблем нет (и опять же мне потребуется только ядро заменить, но не сами модули), но обвязка в виде тэгов в XML мне несколько мешает - в ini это значительно удобнее и нагляднее.
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Старая, но актуальная тема хранения настроек

Сообщение Borjomy_1 »

У меня сейчас "боевые" версии на инишних файлах. правда, так как параметров хранится очень много и они еще меняются по размерам, то хранение комбинированное - кластеры в строках. Кстати, на RT доступ к лицевой панели отсутствует. Даже версию контрола получить не удастся... Поэтому от такой идеи пришлось отказаться. И, чтобы не городить для каждой платформы свои несовместимые методы, требуется остановиться на том, что работает везде.
P.S. Эта-же система обработки настроек у меня вставлена в обмен между контроллерами и рабочей станцией.
yakuba26
junior
junior
Сообщения: 66
Зарегистрирован: 13 дек 2018, 13:55
Версия LabVIEW: 2018
Откуда: Саратов

Re: Старая, но актуальная тема хранения настроек

Сообщение yakuba26 »

Подскажите в каких случаях вы используете хранение настроек? :think:
Artem.spb

Activity Автор
professor
professor
Сообщения: 3391
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Старая, но актуальная тема хранения настроек

Сообщение Artem.spb »

yakuba26 писал(а):Подскажите в каких случаях вы используете хранение настроек? :think:
Во всех, когда этого хочет заказчик (заказчиком могу быть и я сам).
Все переменные, которые может потребоваться менять в ходе эксплуатации проще вынести в настройки, тогда не придётся перекомпилировать по каждому поводу.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Сохранение данных»