Почему не работает видимость в условном оформлении управляемой формы 1С и как это исправить?

← На главную

Каждый разработчик на платформе «1С:Предприятие 8.3», осваивающий технологии управляемого интерфейса, стремится минимизировать объем ручного кодирования. Платформа предоставляет для этого мощный декларативный инструмент — Условное оформление формы. Казалось бы, задача проста: если на форме не заполнен один реквизит (например, ссылка на справочник), то другое связанное поле должно автоматически скрываться. Настроив условное оформление через конфигуратор без единой строчки кода, мы ожидаем увидеть результат, но... ничего не происходит. Поле по-прежнему остается видимым.

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

Почему условное оформление не меняет видимость полей шапки?

Давайте проанализируем поведение платформы. Условное оформление управляемой формы имеет жесткое разделение по типам элементов, к которым оно применяется. Разработчики часто упускают этот момент, из-за чего сталкиваются с неочевидным поведением интерфейса.

В управляемом интерфейсе элементы делятся на две основные группы:

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

Для этих двух групп правила работы условного оформления кардинально различаются:

Для элементов таблиц свойства Видимость, Доступность и ТолькоПросмотр работают в условном оформлении полноценно. Вы можете легко скрыть колонку таблицы для конкретных строк на основе заданных условий.
Для полей шапки свойства Видимость, Доступность, ТолькоПросмотр, Текст и ОтметкаНезаполненного через условное оформление формы не управляются. Платформа физически игнорирует эти настройки. Вы можете настроить для полей шапки изменение цвета фона (ЦветФона), цвета текста (ЦветТекста) или шрифта (Шрифт), но управлять их отображением на форме не получится.

Это архитектурное ограничение платформы «1С:Предприятие». Изменение видимости одиночных элементов интерфейса требует динамического пересчета всей компоновки формы (так как скрытие поля приводит к сдвигу соседних элементов). Выполнение таких тяжелых операций на клиенте через движок условного оформления не предусмотрено разработчиками платформы из соображений производительности.

Как правильно управлять видимостью полей шапки?

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

Рассмотрим этот процесс по шагам на практическом примере. Представим, что у нас есть документ, на форме которого расположены два реквизита: ПлатежнаяКарта (тип — СправочникСсылка.ПлатежныеКарты) и ПлатежнаяКартаСумма (тип — Число). Наша задача — показывать поле ввода суммы только тогда, когда заполнено поле платежной карты.

Шаг 1. Создание вспомогательной процедуры управления видимостью

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

Добавим в модуль управляемой формы следующий код:


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

Обратите внимание: мы обращаемся к реквизиту через структуру Объект (так как это реквизит документа), а к элементу формы — через коллекцию Элементы.

Шаг 2. Обработка интерактивного изменения реквизита пользователем

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

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

Код обработчика будет выглядеть следующим образом:


&НаКлиенте
Процедура ПлатежнаяКартаПриИзменении(Элемент)
    
    // Вызываем обновление видимости при изменении значения пользователем
    УстановитьВидимостьПолейДетализации();
    
КонецПроцедуры

Шаг 3. Установка видимости при открытии формы

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

Для этого лучше всего использовать клиентский обработчик ПриОткрытии:


&НаКлиенте
Процедура ПриОткрытии(Отказ)
    
    // Устанавливаем корректную видимость элементов при первоначальном отображении формы
    УстановитьВидимостьПолейДетализации();
    
КонецПроцедуры

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


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Установка видимости на стороне сервера при инициализации формы
    Элементы.ПлатежнаяКартаСумма.Видимость = ЗначениеЗаполнено(Объект.ПлатежнаяКарта);
    
КонецПроцедуры

Почему 1С рекомендует настраивать интерфейс и оформление программно?

В процессе обсуждения этой проблемы разработчики часто спорят о том, стоит ли вообще использовать интерактивное условное оформление (через свойства формы в конфигураторе) или лучше делать все исключительно кодом. Официальные стандарты разработки фирмы «1С» дают на этот счет однозначные рекомендации.

Рекомендуется настраивать условное оформление и свойства элементов управляемых форм программно в коде модуля формы.

Выделим ключевые причины, почему ручное написание кода предпочтительнее визуальной настройки "мышкой" в конфигураторе:

Контроль целостности метаданных при рефакторинге. Если вы настроите условное оформление интерактивно, укажете там оформляемые поля и условия, а затем через какое-то время переименуете реквизит объекта или удалите его, конфигуратор не выдаст никаких предупреждений. Синтаксический контроль пройдет успешно, но условное оформление молча перестанет работать (связи станут "битыми"). Если же логика прописана кодом, то при проверке конфигурации или компиляции система сразу укажет на синтаксическую ошибку обращения к несуществующему реквизиту.
Упрощение поддержки и групповой разработки. При сравнении и объединении конфигураций (особенно в распределенных командах, использующих Git или хранилище 1С) текстовый код модулей легко поддается автоматическому слиянию. Изменения, внесенные в структуру графической формы (где хранится интерактивное условное оформление), объединять визуально гораздо сложнее, что увеличивает риск потери настроек при обновлении конфигурации.
Читаемость и наглядность бизнес-логики. Открывая модуль формы, программист сразу видит всю логику поведения интерфейса в процедурах ПриИзменении, ПриСозданииНаСервере и других. Если же часть логики скрыта внутри XML-структуры настроек формы конфигуратора, ее очень сложно отлаживать и анализировать новому разработчику.
Повторное использование кода. Создав общие правила оформления (например, функцию выделения просроченной задолженности красным цветом или сокрытия банковских реквизитов для физических лиц), вы можете вынести этот код в общий модуль. После этого в любой форме конфигурации достаточно будет вызвать одну строку общего модуля, передав туда нужные элементы. С интерактивным оформлением вам пришлось бы настраивать правила вручную для каждой новой формы.

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