Как отследить изменение периода в форме списка документов на обычных формах?

При работе с журналами документов в 1С часто возникает задача выполнить определенное действие, когда пользователь меняет стандартный интервал дат. Например, необходимо пересчитать какие-то данные, обновить сложный отбор или переформировать вспомогательный список. Проблема в том, что для стандартной команды установки периода нет прямого события "ПриИзмененииПериода".

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

Решение 1: Использование события формы `ОбновлениеОтображения`

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

Суть метода: мы заводим в модуле формы переменные для хранения предыдущих значений даты начала и даты окончания периода. В обработчике события ОбновлениеОтображения() мы сравниваем текущие даты периода с сохраненными. Если они отличаются — значит, период был изменен, и мы можем запустить нашу процедуру.

Разберем по шагам:

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

Посмотрим на пример кода:

// В разделе переменных модуля обычной формы
Перем мПредыдущаяДатаНачала;
Перем мПредыдущаяДатаОкончания;

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

// Обработчик события "ОбновлениеОтображения" формы
Процедура ОбновлениеОтображения()

    // Получаем текущие значения стандартного периода из элемента формы (табличного поля)
    ТекущаяДатаНачала = ЭлементыФормы.Список.СтандартныйПериод.ДатаНачала;
    ТекущаяДатаОкончания = ЭлементыФормы.Список.СтандартныйПериод.ДатаОкончания;

    // Сравниваем текущие значения с теми, что мы сохранили ранее
    Если мПредыдущаяДатаНачала <> ТекущаяДатаНачала 
         Или мПредыдущаяДатаОкончания <> ТекущаяДатаОкончания Тогда

        // Если есть отличия, значит период изменился.
        // Вызываем нашу основную процедуру
        ВыполнитьТяжелуюПроцедуруПриСменеПериода(ТекущаяДатаНачала, ТекущаяДатаОкончания);

        // И не забываем обновить сохраненные значения для следующей проверки!
        мПредыдущаяДатаНачала = ТекущаяДатаНачала;
        мПредыдущаяДатаОкончания = ТекущаяДатаОкончания;

    КонецЕсли;

КонецПроцедуры

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

Этот метод хорошо подходит для большинства задач. Он не перегружает систему лишними проверками и надежно отлавливает нужное нам событие.

Решение 2: Использование события `ПриПолученииДанных` (Альтернативный вариант)

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

Логика здесь абсолютно такая же, как и в первом решении: сравниваем текущий период с сохраненным. Однако есть важный нюанс, который отметил автор вопроса.

Недостаток: событие ПриПолученииДанных() вызывается очень часто. Хотя сама "тяжелая" процедура будет выполняться только при реальной смене периода, сама проверка дат будет происходить при каждом чихе пользователя (например, при скроллинге). Для простых проверок это некритично, но если логика усложнится, это может создать лишнюю, хоть и небольшую, нагрузку.

Поэтому метод с ОбновлениеОтображения() является более предпочтительным как более экономный.

Решение 3: Оптимизация для действительно "тяжелых" процедур

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

Подход А: Отложенный запуск

Пользователь может несколько раз быстро менять даты в диалоге установки периода. Чтобы не запускать тяжелую процедуру на каждое промежуточное изменение, можно использовать обработчик ожидания. Он запустит расчет один раз, спустя небольшую паузу после того, как пользователь закончит свои действия.

1. При обнаружении смены периода (методом из Решения 1) мы не запускаем процедуру сразу.
2. Вместо этого мы запускаем однократный обработчик ожидания с задержкой в 1-2 секунды: ПодключитьОбработчикОжидания("ИмяПроцедурыРасчета", 1.5, Истина).
3. Если за это время пользователь снова меняет период, мы сначала отключаем предыдущий обработчик ожидания, а потом подключаем новый.

Это гарантирует, что тяжелая операция выполнится только один раз, после финальной настройки периода.

Подход Б: Фоновые задания

Это самый правильный способ для длительных операций (дольше 2-3 секунд), чтобы не блокировать интерфейс пользователя.

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

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

Итог: для стандартной задачи отслеживания смены периода в обычных формах лучше всего подходит метод с проверкой дат в событии ОбновлениеОтображения(). Если же процедура, связанная с этим событием, вызывает заметные "тормоза" интерфейса, рассмотрите возможность ее оптимизации с помощью отложенного запуска или переноса в фоновое задание.