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