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

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

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

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

Ограничения механизма внешних отчетов и обработок (БСП)

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

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

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

  1. Команда на форме остается видимой всегда.
  2. При нажатии на кнопку в процедуре Печать или ВыполнитьКоманду выполняется проверка состояния документа.
  3. Если документ не проведен или нужные реквизиты не заполнены, выполнение прерывается с выводом понятного сообщения пользователю через ПоказатьПредупреждение или генерацию исключения.

Посмотрим на пример такой проверки внутри подключаемой внешней обработки:


&НаКлиенте
Процедура ВыполнитьКоманду(ИмяКоманды, ОбъектыНазначения, ПараметрыВыполнения) Экспорт
    
    Для Каждого СсылкаНаДокумент Из ОбъектыНазначения Цикл
        
        Если Не ПроверитьУсловияВыполнения(СсылкаНаДокумент) Тогда
            ПоказатьПредупреждение(, "Команда доступна только для проведенных документов с заполненным контрагентом!");
            Возврат;
        КонецЕсли;
        
        // Основная логика обработки
        ВыполнитьДействие(СсылкаНаДокумент);
        
    КонецЦикла;
    
КонецПроцедуры

Реализация через расширение конфигурации

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

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

  1. Добавляем в расширение целевой документ и его управляемую форму.
  2. Добавляем на форму собственную команду и размещаем соответствующую кнопку в командной панели или в нужной группе элементов.
  3. Определяем логику обновления состояния интерфейса в зависимости от событий жизненного цикла формы.

Точки перехвата событий формы

Чтобы состояние кнопки всегда соответствовало данным документа, необходимо перехватить несколько стандартных обработчиков событий формы с помощью аннотации &После:

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

Рассмотрим пример программного кода в модуле расширения формы документа:


&НаКлиенте
Процедура Расш_ПослеЗаписиПосле(ПараметрыЗаписи)
    ОбновитьСостояниеКнопокНаКлиенте();
КонецПроцедуры

&НаКлиенте
Процедура Расш_ПриОткрытииПосле(Отказ)
    ОбновитьСостояниеКнопокНаКлиенте();
КонецПроцедуры

&НаКлиенте
Процедура Расш_ОрганизацияПриИзмененииПосле(Элемент)
    ОбновитьСостояниеКнопокНаКлиенте();
КонецПроцедуры

&НаКлиенте
Процедура ОбновитьСостояниеКнопокНаКлиенте()
    
    // Проверяем простые условия на клиенте без серверных вызовов
    КнопкаДолжнаБытьАктивна = Объект.Проведен И ЗначениеЗаполнено(Объект.Организация);
    
    // Управление доступностью или видимостью
    Элементы.Расш_СпециальнаяКоманда.Доступность = КнопкаДолжнаБытьАктивна;
    
КонецПроцедуры

Видимость или доступность: что выбрать?

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

  1. Управление свойством Видимость (Элементы.ИмяКнопки.Видимость = Ложь). Полностью убирает кнопку из формы. Это может приводить к визуальным скачкам командной панели и интерфейса при переключении статусов документа.
  2. Управление свойством Доступность (Элементы.ИмяКнопки.Доступность = Ложь или Команды.ИмяКоманды.Доступность = Ложь). Кнопка остается на привычном месте, но становится серой и неактивной для нажатия. Это поведение более предсказуемо и стабильно для восприятия пользователя.

Оптимизация клиент-серверного взаимодействия

Проанализируем производительность при проверке условий:

  1. Если условия зависят только от реквизитов, уже присутствующих в основном реквизите формы Объект (например, Объект.Проведен, Объект.СуммаДокумента), расчет видимости и доступности следует выполнять на клиенте без лишних серверных контекстных вызовов.
  2. Если для проверки требуются тяжелые запросы к регистру или базе данных, логику проверки следует вынести в отдельную серверную функцию (например, &НаСервереБезКонтекста) и вызывать ее только при создании формы или после записи документа.
← На главную