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