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