При активной разработке в среде 1С программисты часто сталкиваются с крайне неприятной ситуацией: в расширение заимствуется стандартная управляемая форма, на нее добавляется новый реквизит и соответствующий ему элемент управления (поле ввода, флажок и т.д.). В самом конфигураторе при проверке отображения формы по сочетанию клавиш Ctrl + R все выглядит идеально — новый элемент находится на своем месте. Однако при запуске базы в режиме «1С:Предприятие» добавленный реквизит загадочным образом исчезает с экрана.
Эта проблема имеет несколько технических корней: от банальной невнимательности при заимствовании метаданных до серьезных багов динамического обновления и кэширования платформы. Давайте подробно разберем эту ситуацию, проанализируем причины ее возникновения и рассмотрим все эффективные способы решения.
Начнем с самой распространенной методологической ошибки, которую совершают как начинающие, так и опытные разработчики. Когда мы добавляем новый реквизит в объект метаданных (например, новый реквизит в заимствованный документ) внутри расширения, нам необходимо корректно связать его с интерфейсной частью.
Вынося этот реквизит на форму, платформа автоматически прописывает его ПутьКДанным (например, Объект.ИмяНовогоРеквизита). Но если сам реквизит Объект (имеющий тип ДанныеФормыСтруктура) на форме не был заимствован в расширение, то в режиме «1С:Предприятие» связь теряется. Форма физически не знает о существовании нового поля в структуре объекта, из-за чего платформа автоматически скрывает этот элемент интерфейса во избежание критических ошибок.
Решение по шагам:
Платформа 1С очень бережно относится к персональным настройкам пользователей. Механизм сохранения настроек (доступный по кнопке Ещё -> Изменить форму) записывает структуру элементов формы для каждого пользователя индивидуально.
Если вы или тестировщик хотя бы один раз открывали эту форму в режиме «1С:Предприятие» до того, как в расширении был добавлен новый элемент управления, платформа запомнила «старый» вид формы. При последующих открытиях система пытается наложить ранее сохраненные пользовательские настройки поверх измененной структуры метаданных из расширения. В итоге новый элемент просто отбрасывается механизмом компоновки интерфейса.
Решение по шагам:
Если требуется очистить кэш настроек сразу для всех пользователей информационной базы, выполним следующие действия:
Даже если у вашей учетной записи в основной конфигурации назначена роль с полными правами, это не гарантирует автоматическое получение прав на объекты и реквизиты, созданные внутри расширения. Платформа строго изолирует новые метаданные расширения.
Если в расширении была создана хотя бы одна собственная роль или заимствована стандартная роль из основной конфигурации, система безопасности начинает жестко контролировать права на чтение и просмотр новых реквизитов. Если у текущего пользователя нет явного права на просмотр нового реквизита, связанное с ним поле на управляемой форме будет скрыто платформой без вывода каких-либо предупреждений.
Решение по шагам:
Расш1_ОсновнаяРоль) или заимствуем роль ПолныеПрава.Технология расширений позиционируется как безопасная альтернатива динамическому обновлению, однако под капотом она использует схожие механизмы компиляции метаданных «на лету». Это нередко приводит к рассинхронизации локального кэша на сервере или клиенте. Форма в режиме предприятия инициализируется по старым схемам, игнорируя новые реквизиты.
Способы борьбы с кэшем:
/ClearCache в строке запуска или полностью удалить базу из списка запуска и добавить ее заново (при этом папки с кэшем в каталогах %userprofile%\AppData\Local\1C и %userprofile%\AppData\Roaming\1C будут пересозданы).ragent), зайти в каталог расположения реестра кластера (по умолчанию C:\Program Files\1cv8\srvinfo) и удалить временные папки кэша (папки формата snccntx...). После этого запустим службу заново.Если все предыдущие шаги были выполнены, но реквизит по-прежнему упорно не желает появляться в режиме «1С:Предприятие», мы имеем дело с известным платформенным багом. В релизах линеек 8.3.15 и 8.3.16 наблюдалась системная ошибка динамического слияния метаданных, когда новые реквизиты табличных частей или шапки документов, добавленные через расширения, физически не попадали в коллекцию элементов формы при инициализации на стороне сервера.
Разработчики на форумах нашли крайне элегантный и работающий обходной путь (workaround), основанный на понижении режима совместимости расширения на этапе проектирования интерфейса.
Как реализовать обходной путь:
Рассмотрим пример того, как мы можем программно проверить, создается ли элемент формы при инициализации, добавив отладочный код в обработчик события формы в расширении. Это поможет локализовать проблему и понять, видит ли сервер данный элемент вообще:
&НаСервере
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверим, существует ли добавленный нами элемент в коллекции формы на сервере
ИмяПроверяемогоЭлемента = "Расш1_МойНовыйРеквизит";
НайденныйЭлемент = Элементы.Найти(ИмяПроверяемогоЭлемента);
Если НайденныйЭлемент = Неопределено Тогда
// Если элемент не найден, значит имеет место баг платформы или проблема кэша метаданных
ЗаписьЖурналаРегистрации(
"ПроверкаРасширения",
УровеньЖурналаРегистрации.Предупреждение,
,
,
"Элемент '" + ИмяПроверяемогоЭлемента + "' не обнаружен в коллекции элементов формы при создании на сервере!"
);
Иначе
// Если элемент найден, проверим его видимость и доступность
НайденныйЭлемент.Видимость = Истина;
НайденныйЭлемент.Доступность = Истина;
КонецЕсли;
КонецПроцедуры
Используя данный метод программной проверки, мы сможем однозначно определить, на каком этапе происходит скрытие элемента: на этапе генерации формы сервером 1С или на этапе клиентской отрисовки под влиянием пользовательских настроек интерфейса.