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