При разработке сложных интерфейсов на управляемых формах 1С часто возникает необходимость добавлять элементы управления динамически, «на лету», в зависимости от условий работы пользователя или настроек системы. Однако при создании таких реквизитов программно разработчики сталкиваются с ограничением: у них нет возможности просто «включить» флаг автоматического сохранения в настройках, как это делается для реквизитов, созданных в Конфигураторе.
В этой статье мы подробно разберем, почему возникает такая ситуация и как правильно реализовать сохранение значений ваших динамических реквизитов, чтобы они не терялись после закрытия формы.
Механизм АвтоматическоеСохранениеДанныхВНастройках жестко привязан к структуре формы, которая была определена на этапе проектирования в Конфигураторе. Когда платформа инициализирует форму, она считывает метаданные и регистрирует все реквизиты, помеченные для сохранения. В этот момент динамически созданные реквизиты (добавленные методом ИзменитьРеквизиты) еще не существуют в объекте формы.
Внутренняя архитектура платформы не поддерживает «подключение» новых реквизитов к уже запущенному механизму автосохранения. Поэтому попытки найти соответствующий флаг в Справочнике разработчика или методах API будут безуспешными — программной установки флага для таких объектов просто не существует. Это архитектурное ограничение, и его нужно принимать как данность.
Раз мы не можем использовать «магическую галочку», мы воспользуемся штатным механизмом событий формы, специально предназначенным для управления пользовательскими настройками. Нам потребуются два ключевых обработчика, которые вызываются платформой автоматически при закрытии и открытии формы.
Прежде всего, убедитесь, что в свойствах формы включено Автоматическое сохранение данных в настройках. Это активирует инфраструктуру работы с настройками в принципе. Чтобы платформа «поняла», что настройки нужно сохранить, необходимо сигнализировать о модификации данных.
В процедуре ПриОткрытии мы устанавливаем флаг модифицированности:
&НаКлиенте
Процедура ПриОткрытии(Отказ)
// Устанавливаем флаг, чтобы при закрытии сработал обработчик сохранения
СохраняемыеВНастройкахДанныеМодифицированы = Истина;
КонецПроцедуры
В этом обработчике мы будем «складывать» значения наших программных реквизитов в коллекцию Настройки. Это коллекция типа Соответствие, которая будет сериализована платформой и записана в хранилище настроек.
&НаСервере
Процедура ПриСохраненииДанныхВНастройкахНаСервере(Настройки)
// Сохраняем значение нашего программного реквизита
// Допустим, программный реквизит называется "МойДинамическийРеквизит"
Настройки.Вставить("КлючНастройки", МойДинамическийРеквизит);
КонецПроцедуры
Когда пользователь снова откроет форму, платформа вызовет процедуру загрузки. Нам остается лишь извлечь данные из соответствия и присвоить их нашим реквизитам.
&НаСервере
Процедура ПриЗагрузкеДанныхИзНастроекНаСервере(Настройки)
// Извлекаем значение, если оно было сохранено ранее
ЗначениеИзНастроек = Настройки.Получить("КлючНастройки");
Если ЗначениеИзНастроек <> Неопределено Тогда
МойДинамическийРеквизит = ЗначениеИзНастроек;
КонецЕсли;
КонецПроцедуры
При работе с настройками часто приходится видеть конструкцию #Если _ Тогда. Давайте проанализируем, зачем она нужна. Символ подчеркивания _ не является предопределенной константой, поэтому условие всегда ложно. Разработчики используют этот прием, чтобы:
НастройкиКомпоновкиДанных) и предлагает методы, даже если сам код никогда не выполнится.Важное примечание: Если вы планируете сохранять сложные структуры, такие как НастройкиКомпоновкиДанных или коллекции, убедитесь, что они сериализуемы. В случае с КомпоновщикомНастроек всегда используйте методы ПолучитьНастройки() для сохранения и загрузки, чтобы избежать проблем с типами данных.
Используя этот подход, вы сможете гибко управлять сохранением любых данных формы, независимо от того, были ли они созданы статически в конфигураторе или программно в процессе работы пользователя.