Почему не срабатывает событие ПередЗагрузкойДанныхИзНастроекНаСервере в управляемой форме?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Разработка внешних обработок и сложных отчетов в 1С часто требует сохранения пользовательских настроек (например, выбранных фильтров, значений переключателей или состояния элементов интерфейса). Платформа 1С:Предприятие 8.3 предоставляет для этого стандартный механизм и два ключевых события: ПередЗагрузкойДанныхИзНастроекНаСервере и ПриСохраненииДанныхВНастройкахНаСервере. Однако программисты часто сталкиваются с тем, что эти обработчики просто не вызываются. Разберемся подробно, почему это происходит и как заставить механизм работать корректно.

Причина 1: Отсутствие «сохраняемых данных» в свойствах формы

Самая распространенная причина, по которой события «молчат» — платформе нечего сохранять. Если вы просто установили в свойствах формы флаг АвтоматическоеСохранениеДанныхВНастройках в значение Использовать, этого недостаточно. Рассмотрим, как работает логика платформы: она оптимизирует вызовы и не инициирует серверные события загрузки или сохранения, если в списке сохраняемых реквизитов пусто.

Проанализируем шаги для исправления этой ситуации:

  1. Откройте форму вашей обработки в конфигураторе.
  2. Перейдите в свойства формы.
  3. Найдите свойство Сохраняемые данные (не путать с автоматическим сохранением).
  4. Нажмите на кнопку открытия списка и отметьте галочками те реквизиты формы, значения которых должны запоминаться (например, Организация, Период или любой другой реквизит).

Важно: Если вы хотите сохранять настройки компоновщика (фильтры СКД), помните, что у самого реквизита типа КомпоновщикНастроекКомпоновкиДанных нет флага сохранения. В этом случае нужно использовать «хитрость» с дополнительным реквизитом, которую мы разберем ниже.

Причина 2: Пустое хранилище или отсутствие ключа

Событие ПередЗагрузкойДанныхИзНастроекНаСервере не будет вызвано, если в системном хранилище настроек еще нет записи для данной формы. Это происходит при самом первом запуске обработки пользователем или после очистки настроек. Платформа проверяет наличие данных в SystemSettingsStorage, и если записи нет, загружать нечего — следовательно, событие не инициируется.

Для внешних обработок критически важна идентификация. Если обработка открывается просто через меню «Файл — Открыть», платформа может генерировать разные ключи или вовсе не находить соответствие. Чтобы избежать проблем с идентификацией, рекомендуется программно устанавливать уникальный ключ сохранения настроек в обработчике ПриСозданииНаСервере:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    // Устанавливаем уникальный идентификатор для хранения настроек
    ЭтаФорма.КлючСохраненияПоложенияОкна = "УникальныйКлючМоейОбработки_Версия1";
КонецПроцедуры

Причина 3: Использование «фиктивного» реквизита для принудительного вызова

Рассмотрим ситуацию, когда стандартные реквизиты не меняются, но нам нужно сохранить состояние интерфейса или настройки компоновщика. Как выяснили опытные разработчики, события сохранения/загрузки жестко привязаны к изменению реквизитов, помеченных как сохраняемые данные. Если такие реквизиты визуально не менялись пользователем, платформа может пропустить вызов ПриСохраненииДанныхВНастройкахНаСервере.

Разберем решение этой проблемы через создание «фиктивного» реквизита-индикатора:

  1. Добавьте в реквизиты формы новый элемент, например, МодификаторНастроек с типом Число.
  2. Включите его в список Сохраняемые данные в свойствах формы.
  3. В коде, где вы меняете настройки программно (например, при скрытии или показе отборов), принудительно меняйте значение этого реквизита.

Пример реализации логики в коде формы:


&НаКлиенте
Процедура КомандаИзменитьОтбор(Команда)
    // Какая-то логика изменения настроек компоновщика
    // ...
    
    // Принудительно «пачкаем» форму, чтобы вызвать сохранение
    МодификаторНастроек = МодификаторНастроек + 1;
КонецПроцедуры

&НаСервере
Процедура ПриСохраненииДанныхВНастройкахНаСервере(Настройки)
    // Теперь это событие гарантированно сработает, 
    // так как МодификаторНастроек изменился
    Настройки.Вставить("МойКомпоновщикНастроек", ЭтаФорма.Отчет.КомпоновщикНастроек.ПолучитьНастройки());
КонецПроцедуры

Причина 4: Программный вызов загрузки настроек

Иногда автоматический цикл событий не подходит под бизнес-логику приложения. В таких случаях мы можем самостоятельно инициировать процесс загрузки. Для этого используется метод формы ЗагрузитьДанныеИзНастроек(). Выясним, как это работает: вызов данного метода принудительно запускает цепочку событий на сервере, даже если платформа считала, что загрузка не требуется.

Проанализируем пример использования в ПриОткрытии:


&НаКлиенте
Процедура ПриОткрытии(Отказ)
    // Если автоматика не сработала, вызываем загрузку вручную
    ЭтаФорма.ЗагрузитьДанныеИзНастроек();
КонецПроцедуры

Внимание: Будьте осторожны с рекурсивными вызовами и порядком инициализации объектов. Событие ПередЗагрузкойДанныхИзНастроекНаСервере происходит после ПриСозданииНаСервере. Если вы в ПриСозданииНаСервере жестко прописали значения реквизитов, они могут быть перезаписаны данными из настроек сразу после завершения процедуры создания.

Дополнительные нюансы для внешних обработок

Если ваша обработка работает в составе БСП (Библиотеки Стандартных Подсистем) как дополнительный отчет или обработка, механизм сохранения настроек может перехватываться программным кодом БСП. В этом случае настройки часто сохраняются не в стандартное системное хранилище, а в регистр сведений Сохраненные настройки или аналогичные структуры данных БСП.

Посмотрим, на что стоит обратить внимание в этом случае:

Подводя итог: для корректной работы событий ПередЗагрузкойДанныхИзНастроекНаСервере и ПриСохраненииДанныхВНастройкахНаСервере всегда проверяйте наличие реквизитов в списке Сохраняемые данные и наличие уникального Ключа сохранения. Если автоматика подводит — используйте метод ЗагрузитьДанныеИзНастроек() или изменение фиктивного реквизита для инициации процесса записи.

← На главную