Формат хранения пользовательских настроек формы

[Logger]

Привет всем.

Коллеги, а кто-нибудь разбирал формат хранения пользовательских настроек форм ?
Зачем :
1. Пользователь настраивает форму в аксапте под себя.
2. Программисты выкатывают обновление.
3. Пользовательские настройки формы становятся неприменимы (падает аксапта, кривится форма итп)
4. Приходится сбрасывать настройки чтобы восстановить нормальное функционирование формы.
5. Пользователь матерится и заново повторяет все настройки.

Можно как-то этого избежать ?
Понять как хранятся настройки и пофиксить.
Или может быть при выполнении пользователем настроек формы вести свой лог действий юзера при настройке, так что его можно повторить после сброса.

Может кто-то это уже делал ?

[TasmanianDevil]

IMHO, овчинка не стоит выделки - состав контейнера настроек, сохраняемых в pack() у FormRun, закрыт, в отличии , например, от поголовья RunBase'овских наследников, где при изменении структуры сохраняемых параметров можно имеющимся сохраненным настройкам провести правильную "хирургию".

[Товарищ ♂uatr]

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

ИХМО Стоит вернуться на шаг назад и задаться вопросами: "Кто этот пользователь формы? Много ли таких пользователей? Что их объединяет? Можно ли их разбить на группы? Каковы их функциональные обязанности?"
Текущее решение - одно из множества. Есть ли более удачные? Выделение отдельной формы для специфической категории пользователей, например, решит проблему?

В коробочной версии данные в контейнере лежат в рамках ключа ControlNameControlId последовательность соответствует указанной в дизайне. Меняем ключ - получаем неработоспособную настройку объекта.
Понятное дело, что можно изменить подход к "пакетированию" данных реализовав расширение к стандартной xSysLastValue (в противовес быстродействию при открытии и закрытии формы).
Но перед тем как пытаться изменить подход к упаковке данных, стоит ответить на 2 вопроса:
А какие именно действия программиста приводят к возникновению данной проблемы?
А какие именно пользовательские настройки ломаются?
С программистом, вроде, всё просто: это может быть добавление, удаление, перемещение в дизайне и переименование объекта.
В итоге получаем двумерную матрицу "Действий разработчика" на "Настройки пользователя" и отмечаем, что делать можно.

[ivas]

Вы можете сами сохранять некоторые важные для пользователя настройки параллельно в своем формате. Например последовательность колонок в гридах сохранять в контейнере или json формате с помощью

xSysLastValue::putValue(...)

и при инициализации формы двигать только те колонки для которых есть настройка.

[Logger]

Цитата:

Сообщение от ivas

Вы можете сами сохранять некоторые важные для пользователя настройки параллельно в своем формате. Например последовательность колонок в гридах сохранять в контейнере или json формате с помощью

xSysLastValue::putValue(...)

и при инициализации формы двигать только те колонки для которых есть настройка.

Собственно так и хотим сделать. Прикрутить в редактор что-то типа лога и затем по желанию юзера по логу прокручивать и автоматически все нужные изменения вносить.

[ivas]

Делал подобное для сохранения пользовательского порядка полей в SysTableBrowser.
пункт - "Пользовательский" (в радиобаттоне справа)
вот Form_SysTableBrowser_Dev.xpo проект для 2009