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

← На главную

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

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

Почему условное оформление не всегда подходит для кнопок

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

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

Выясним причины нестабильности УО в данном контексте:

Кэширование состояния: УО для элементов формы (не таблиц) пересчитывается при изменении реквизитов, задействованных в условии. Но момент появления ссылки (после записи) не всегда принудительно инициирует обновление оформления именно для командного интерфейса.
Особенности инициализации: При открытии формы нового документа Объект.Ссылка — это пустая ссылка конкретного типа. Для системы УО это заполненное значение определенного типа, и логика «заполнено/не заполнено» может отрабатывать некорректно без явного сравнения с ЗНАЧЕНИЕ(...).

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

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

Разберем реализацию по шагам. Создадим общую процедуру для управления состоянием формы:


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

Теперь эту процедуру необходимо вызвать в стандартных обработчиках событий формы:


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

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
	УстановитьДоступностьКнопокНаСервере();
КонецПроцедуры

&НаСервере
Процедура ПослеЗаписиНаСервере(ПараметрыЗаписи)
	УстановитьДоступностьКнопокНаСервере();
КонецПроцедуры

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

Способ 2. Использование вспомогательного реквизита формы

Если вы все же хотите использовать Условное оформление (например, если нужно динамически менять оформление множества элементов в зависимости от «новости» объекта), лучше всего завести вспомогательный реквизит формы. Платформа гораздо стабильнее отслеживает изменение простых типов (Булево, Число) в УО, чем состояние ссылочных полей.

Выполним следующие действия:

Создадим реквизит формы (не объекта!) с именем ЭтоНовыйОбъект, тип Булево.
В событии ПриСозданииНаСервере инициализируем его:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	ЭтоНовыйОбъект = Объект.Ссылка.Пустая();
КонецПроцедуры

Теперь в настройках Условного оформления формы (на закладке «Условное оформление» в редакторе формы) создадим новое правило:

Оформление: Доступность = Ложь.
Условие: ЭтоНовыйОбъект Равно Истина.
Оформляемые поля: Выбираем вашу кнопку.

Важно помнить, что значение этого реквизита также нужно будет обновить в процедуре ПослеЗаписиНаСервере, установив ЭтоНовыйОбъект = Ложь;, чтобы кнопка «ожила» сразу после сохранения документа.

Способ 3. Проверка в обработчике команды

Иногда вместо того, чтобы скрывать кнопку, целесообразнее оставить ее доступной, но выдавать предупреждение пользователю. Это улучшает UX (пользовательский опыт), так как человек понимает, почему действие недоступно, а не просто видит «пустую» панель.

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


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

Резюме

Подведем итоги нашего исследования. Механизм Условного оформления — мощный инструмент, но для управления доступностью кнопок на основной форме он является не самым надежным решением. Это связано с приоритетом свойств команд над свойствами элементов формы.

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