В процессе разработки на платформе 1С:Предприятие 8.3 часто возникает задача по управлению доступностью полей ввода в зависимости от данных, которые ввел пользователь. Типичный пример: в табличной части документа выбирается тип риска, и в зависимости от этого выбора некоторые колонки в этой же строке должны становиться недоступными для редактирования. Рассмотрим подробно, как реализовать такую логику наиболее эффективно и правильно с точки зрения производительности системы.
Разберем самый современный и производительный способ — использование Условного оформления формы. Его главное преимущество заключается в том, что платформа берет на себя все вычисления. После настройки правил оформления они передаются на клиент, и визуальные изменения (блокировка ячеек) происходят мгновенно при изменении данных, не требуя дополнительных вызовов сервера при каждом переходе между строками.
Проанализируем пошагово процесс настройки через конфигуратор:
ТолькоПросмотр и установим его в значение Истина. Также можно выбрать Доступность = Ложь, однако для управляемых форм предпочтительнее использовать ТолькоПросмотр, чтобы пользователь мог выделить содержимое ячейки, но не мог его изменить.Объект.Риски.ТипРиска Равно "Пожар".РискиБлизостьКАвиалиниям).Выясним причину, почему это лучше программного кода. Если мы настраиваем оформление через интерфейс конфигуратора, система автоматически оптимизирует отрисовку. Как только пользователь меняет значение в колонке Риск, платформа на стороне клиента проверяет условия оформления и моментально блокирует связанные ячейки.
Иногда логика блокировки слишком сложна для простого конструктора условий (например, условия зависят от внешних факторов или сложных расчетов). В таких ситуациях рассмотрим использование события ПриНачалеРедактирования табличной части.
Проанализируем ситуацию: событие ПриАктивизацииСтроки, часто предлагаемое на форумах, не всегда удобно, так как оно срабатывает слишком часто — при каждом перемещении курсора. Событие ПриНачалеРедактирования срабатывает только тогда, когда пользователь реально пытается изменить данные.
Посмотрим на пример кода, который блокирует ввод:
&НаКлиенте
Процедура РискиПриНачалеРедактирования(Элемент, НоваяСтрока, Копирование)
ТекущиеДанные = Элементы.Риски.ТекущиеДанные;
Если ТекущиеДанные <> Неопределено Тогда
// Проверяем значение в текущей строке
Если ТекущиеДанные.ТипРиска = ПредопределенноеЗначение("Перечисление.ТипыРисков.Пожар") Тогда
// Если редактируемое поле — это "БлизостьКАвиалиниям", отменяем редактирование
Если Элементы.Риски.ТекущийЭлемент.Имя = "РискиБлизостьКАвиалиниям" Тогда
Элементы.Риски.ИзменитьСтроку(); // Завершаем режим редактирования
Сообщить("Данное поле недоступно для выбранного типа риска!");
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важный момент: использование параметра Отказ = Истина в некоторых событиях позволяет полностью запретить вход в режим редактирования строки, что является максимально жестким способом блокировки.
Рассмотрим ситуацию, когда список рисков и блокируемых полей хранится в специальном регистре сведений. В этом случае мы не можем «накликать» оформление в конфигураторе, так как условия заранее неизвестны. Нам поможет программное создание элементов УсловноеОформление при создании формы на сервере.
Разберем по шагам, как это реализовать:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Создаем новый элемент условного оформления
ЭлементУО = УсловноеОформление.Элементы.Добавить();
// 1. Что оформляем (блокируем)
ОформляемоеПоле = ЭлементУО.Поля.Элементы.Добавить();
ОформляемоеПоле.Поле = Новый ПолеКомпоновкиДанных("РискиБлизостьКАвиалиниям");
// 2. Условие срабатывания
ЭлементУсловия = ЭлементУО.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементУсловия.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Объект.Риски.ТипРиска");
ЭлементУсловия.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
ЭлементУсловия.ПравоеЗначение = Справочники.ВидыРисков.НайтиПоНаименованию("Пожар");
// 3. Какое свойство меняем
ЭлементУО.Оформление.УстановитьЗначениеПараметра("ТолькоПросмотр", Истина);
КонецПроцедуры
Такой подход объединяет гибкость кода и производительность штатного механизма платформы. Мы один раз при открытии формы сформировали правила, и далее платформа обрабатывает их на клиенте без участия сервера.
Выясним важный технический нюанс, который часто вызывает споры среди разработчиков. При работе с элементами формы Доступность и ТолькоПросмотр ведут себя по-разному:
Ложь, элемент становится «серым». Пользователь не может даже нажать на него или выделить текст. В некоторых случаях это может мешать (например, если нужно скопировать значение из заблокированной ячейки).Внимание: Согласно документации (Синтакс-помощник), изменение свойства Доступность для всей колонки на клиенте обычно не вызывает серверного вызова, однако изменение ТолькоПросмотр для элемента управления может спровоцировать контекстный вызов сервера для пересчета прав и визуального состояния. Именно поэтому Условное оформление является приоритетным — оно избавляет от этих проблем, так как работает в рамках модели данных формы.
Если вы разрабатываете интерфейс для мобильного клиента или работаете в условиях медленного интернет-соединения, крайне не рекомендуется использовать событие ПриАктивизацииСтроки для программного изменения свойств колонок. Каждое такое изменение может приводить к «дерганию» интерфейса и задержкам.
Проанализируем работу мобильной платформы: при использовании Условного оформления мобильное приложение получает инструкции один раз и отрисовывает форму локально. Если же использовать программный код с серверными вызовами, каждое движение по таблице будет сопровождаться ожиданием ответа от сервера, что сделает работу пользователя невыносимой.
Подводя итог нашему анализу, дадим несколько практических советов:
ПриСозданииНаСервере.Элементы.ИмяКолонки.Доступность внутри циклов или событий движения по таблице.Используя эти правила, мы обеспечим быструю работу интерфейса и удобство для конечного пользователя, сохраняя при этом целостность данных в информационной системе.