Как обновить элемент формы при изменении реквизита в обработчике ПодключитьОбработчикИзмененияДанных в 1С?

← На главную

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

В рамках этой статьи мы подробно проанализируем, почему возникает эта проблема, разберем особенности работы графического движка обычных форм 1С и рассмотрим три практических способа ее правильного решения.

Выясняем причину: почему платформа блокирует обновление интерфейса

Для того чтобы понять природу этой проблемы, проанализируем ситуацию на уровне ядра платформы 1С. Когда пользователь или внешний алгоритм изменяет данные отслеживаемого реквизита (например, Реквизит1), платформа запускает зарегистрированную процедуру-обработчик.

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

В результате мы наблюдаем следующие последствия:

Прямое присвоение значения переменной (например, Реквизит2 = "Новое значение";) успешно обновляет данные в оперативной памяти.
Связанный с этим реквизитом элемент управления (особенно декоративный элемент типа "Надпись") не получает сигнал об изменении источника данных и визуально не перерисовывается.
Вызов метода ЭтаФорма.Обновить() внутри обработчика не дает результата, так как с точки зрения платформы данные формы уже считаются синхронизированными, а принудительный графический апдейт игнорируется во время блокировки очереди отрисовки.
Присвоение вида Реквизит2 = Реквизит2 в событии формы ОбновлениеОтображения решает проблему только потому, что это событие срабатывает циклически при любых действиях на экране, принудительно взводя флаг "грязных данных" для элемента. Однако постоянное выполнение этой операции без условий сильно перегружает процессор.

Разберем по шагам, как решить эту задачу правильно и эффективно.

Способ 1. Прямое изменение свойств элементов формы (Рекомендуемый быстрый способ)

Самый простой и логичный способ обойти блокировку автоматической перерисовки — изменить значение не самого реквизита напрямую, а обратиться к его визуальному представлению на форме через коллекцию ЭлементыФормы.

Рассмотрим пример реализации этого подхода. Предположим, у нас есть процедура инициализации обработчика в событии открытия формы:


Процедура ПриОткрытии()
    // Подключаем обработчик изменения данных для Реквизит1
    ЭтаФорма.ПодключитьОбработчикИзмененияДанных("Реквизит1", "ИзменитьЗначениеРеквизита2", Истина);
КонецПроцедуры

Теперь напишем код обработчика, в котором вместо изменения переменной реквизита мы напрямую укажем новое значение для элемента формы:


Процедура ИзменитьЗначениеРеквизита2(ПутьКДанным)
    // Сообщаем в окно сообщений для проверки вызова процедуры
    Сообщить("Значение реквизита Реквизит1 изменилось!");
    
    // Прямое изменение свойства Значение элемента управления формы
    ЭлементыФормы.Реквизит2.Значение = "Значение установлено напрямую через элемент";
КонецПроцедуры

Почему это работает: при непосредственном изменении свойства Значение у объекта коллекции ЭлементыФормы платформа 1С мгновенно обновляет связанный с ним реквизит в памяти и осуществляет принудительную перерисовку конкретного графического поля, обходя общую заблокированную очередь транзакции изменений.

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

ЭлементыФормы.НадписьРеквизита2.Заголовок = "Новый текст надписи";

Способ 2. Оптимизация работы через ОбновлениеОтображения (Если реквизитов много)

Рассмотрим ситуацию, когда в обработчике изменения данных вам необходимо обновить не один, а сразу десяток различных реквизитов на форме. Прописывать каждый из них через обращение к коллекции ЭлементыФормы может быть неудобно и приведет к избыточному коду. В этом случае мы можем задействовать предопределенное событие формы ОбновлениеОтображения, но сделаем это максимально оптимизированно с помощью локального флага.

Разберем по шагам этот алгоритм:

Объявим специальную переменную-флаг в самом начале модуля формы.
В процедуре-обработчике изменения данных установим этот флаг в значение Истина после изменения всех необходимых реквизитов.
В событии формы ОбновлениеОтображения проверим состояние флага, обновим нужные элементы и сбросим его значение.

Посмотрим на пример кода, реализующий этот сценарий:


// Объявляем переменную в начале модуля формы
Перем НеобходимоОбновитьИнтерфейс;

Процедура ПриОткрытии()
    НеобходимоОбновитьИнтерфейс = Ложь;
    ЭтаФорма.ПодключитьОбработчикИзмененияДанных("Реквизит1", "ИзменитьЗависимыеРеквизиты", Истина);
КонецПроцедуры

Процедура ИзменитьЗависимыеРеквизиты(ПутьКДанным)
    // Программное изменение группы реквизитов в памяти
    Реквизит2 = "Новое значение для поля 2";
    Реквизит3 = "Новое значение для поля 3";
    Реквизит4 = "Новое значение для поля 4";
    
    // Взводим флаг для последующей перерисовки
    НеобходимоОбновитьИнтерфейс = Истина;
КонецПроцедуры

Процедура ОбновлениеОтображения()
    // Проверяем, был ли взведен флаг обновления
    Если НеобходимоОбновитьИнтерфейс Тогда
        
        // Заставляем систему перерисовать элементы, присваивая реквизиты сами себе
        Реквизит2 = Реквизит2;
        Реквизит3 = Реквизит3;
        Реквизит4 = Реквизит4;
        
        // Сбрасываем флаг, чтобы исключить циклическую нагрузку на процессор
        НеобходимоОбновитьИнтерфейс = Ложь;
        
    КонецЕсли;
КонецПроцедуры

Такой подход позволяет избежать лишней нагрузки на систему. Код перерисовки выполнится ровно один раз сразу после того, как управление вернется из обработчика изменений обратно к интерфейсному потоку платформы.

Способ 3. Переход на событийную модель зависимостей (Архитектурно верный подход)

Проанализируем ситуацию с точки зрения хорошего тона разработки (Best Practice). Использование метода ПодключитьОбработчикИзмененияДанных для простых реквизитов формы (не табличных частей, не динамических списков) часто считается избыточным и усложняет чтение кода сторонними разработчиками.

Если значения реквизитов на вашей форме меняются как пользователем интерактивно, так и кодом программы, правильнее спроектировать явную событийную модель зависимостей.

Давайте посмотрим, как реализовать такую архитектуру:

Создадим единую процедуру для изменения базового реквизита:


Процедура УстановитьРеквизит1(НовоеЗначение) Экспорт
    Реквизит1 = НовоеЗначение;
    
    // Сразу же вычисляем и обновляем зависимые данные
    Реквизит2 = "Зависимое значение для: " + НовоеЗначение;
    
    // Принудительно обновляем элемент интерфейса
    ЭлементыФормы.Реквизит2.Значение = Реквизит2;
КонецПроцедуры

На форме для элемента управления, связанного с Реквизит1, определим стандартный обработчик события ПриИзменении:


Процедура Реквизит1ПриИзменении(Элемент)
    // Вызываем нашу единую процедуру изменения данных
    УстановитьРеквизит1(Реквизит1);
КонецПроцедуры

Во всех остальных процедурах модуля формы, где требуется программно изменить Реквизит1, откажемся от прямого присвоения Реквизит1 = "..." и будем вызывать процедуру УстановитьРеквизит1("...").

Использование этого подхода полностью исключает необходимость применения сложных асинхронных обработчиков изменения данных, делает код предсказуемым и значительно облегчает его последующую отладку и сопровождение.

Перспективы миграции на управляемый интерфейс 1С 8.3

В заключение проанализируем важный нюанс, связанный с развитием платформы «1С:Предприятие». Если в будущем вы планируете переводить вашу конфигурацию или внешнюю обработку на современные Управляемые формы, учитывайте, что метод ПодключитьОбработчикИзмененияДанных полностью отсутствует в тонком и веб-клиенте 1С 8.3.

Переход на событийную модель, описанную в "Способе 3", уже на этапе работы в обычных формах гарантирует, что при миграции на управляемый интерфейс вам не придется кардинально переписывать архитектуру логики формы с нуля. Вам достаточно будет лишь перенести вызовы процедур в контекст клиента и сервера без необходимости эмуляции низкоуровневых обработчиков платформы.