В процессе обновления нетиповых конфигураций разработчики часто сталкиваются с ситуацией, когда штатный отчет о сравнении объектов фиксирует изменение управляемой формы или ее элементов, однако визуальное сопоставление в редакторе форм практически не показывает различий (например, отличается лишь ширина одной колонки). Разберем, из-за чего механизм сравнения и объединения считает формы разными, какие скрытые параметры влияют на этот процесс и как безопасно выполнить обновление, не потеряв доработки.
Причины скрытых различий при сравнении форм
Штатный механизм сравнения конфигуратора 1С анализирует метаданные на уровне внутренней объектной структуры. В отличие от модулей с исходным кодом, где различия четко видны построчно, форма представляет собой сложный составной объект. Проанализируем основные факторы, вызывающие фиксацию изменений при отсутствии видимой разницы:
Несовпадение внутренних идентификаторов (UUID). Если в процессе доработки элемент формы, команда или реквизит были удалены и созданы повторно с абсолютно теми же именами и свойствами, платформа считает их разными сущностями. Причиной служат уникальные идентификаторы (GUID), генерируемые заново для каждого нового объекта.
Настройки динамического списка. Динамический список — это не только текст запроса, но и вложенная схема компоновки данных. Изменение отборов по умолчанию, порядка сортировки, группировок, структуры полей или собственного условного оформления динамического списка фиксируется платформой как модификация формы или связанного с ней элемента таблицы. Даже если сам текст запроса идентичен, внутренние настройки списка могут различаться.
Условное оформление формы. Правила условного оформления хранятся во внутренних коллекциях формы. Небольшая корректировка цвета, доступности или состава оформляемых полей часто не бросается в глаза при визуальном осмотре дерева элементов, но помечает объект как измененный.
Служебные параметры и свойства по умолчанию. При смене версии платформы или режима совместимости конфигурации у стандартных элементов могут изменяться значения по умолчанию (например, флаги растягивания по горизонтали/вертикали, автовысота или видимость на мобильных клиентах). Если в одной конфигурации свойство сохранено в XML-описании формы явно, а в другой подставляется неявно как значение по умолчанию, механизм сравнения определит это как расхождение.
Автозаполнение и состав командных панелей. Различия могут скрываться в источниках команд, порядке отображения стандартных кнопок или переопределении флагов автозаполнения для контекстных меню и командных панелей.
Способы точного выявления различий
Когда визуальное сравнение в конфигураторе не дает ответа, выясним точную причину расхождений с помощью специальных инструментов.
Выгрузка конфигураций в файлы и текстовое сравнение XML. Рассмотрим наиболее надежный способ выявления изменений. Выполним выгрузку обеих конфигураций (текущей рабочей и конфигурации поставщика) в файлы через меню Конфигурация — Выгрузить конфигурацию в файлы.... Далее откроем внешнюю программу для сравнения текстовых файлов и сопоставим между собой файлы структуры проблемной формы Form.xml. В текстовом представлении сразу видны удаленные или добавленные теги, измененные GUID элементов, скрытые флаги оформления и скорректированные свойства динамических списков.
Сравнение через буфер обмена. Откроем обе формы параллельно в двух конфигураторах. Скопируем элемент из одной формы и вставим его в дерево элементов второй формы. Если рядом создается дубликат с постфиксом «1» (например, Список1), значит, внутренний идентификатор исходного элемента не совпадает с новым, несмотря на одинаковое имя.
Использование среды 1C:Enterprise Development Tools (EDT). Среда разработки EDT использует объектное представление метаданных и предоставляет более детализированный механизм структурного сравнения элементов управляемых форм по сравнению с классическим конфигуратором.
Оптимальные стратегии обновления измененных форм
Разберем практические варианты действий при объединении форм, когда доработки минимальны, а типовая форма существенно обновлена поставщиком.
Замещение типовой формой с повторным внесением доработок. Если со стороны разработчиков на форме была изменена лишь ширина колонки или добавлен один второстепенный реквизит, попытка полуавтоматического объединения форм может привести к нарушению расположения групп и элементов. В таких ситуациях безопаснее полностью принять форму поставщика (затереть изменения), а затем вручную за несколько минут повторить точечную доработку. Данные базы при этом не теряются, так как реквизиты объектов хранятся в таблицах базы данных независимо от формы.
Вынос доработок интерфейса в расширения конфигурации. Чтобы при последующих обновлениях не анализировать формы вручную, снимем доработку с основной конфигурации и реализуем ее через расширение. Для изменения свойств элементов (включая ширину колонок или добавление реквизитов) используем перехват события формы в расширении:
&НаСервере
Процедура Расш_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Программная корректировка ширины колонки без изменения основной формы
ЭлементКолонка = Элементы.Найти("СсылкаНомер");
Если ЭлементКолонка <> Неопределено Тогда
ЭлементКолонка.Ширина = 15;
КонецЕсли;
КонецПроцедуры
Использование пользовательских настроек в режиме «1С:Предприятие». Если модификация формы заключалась лишь в изменении ширины колонок, видимости полей или расположения списков под конкретных пользователей, не следует вносить такие правки в метаданные конфигуратора. Настроим нужный вид через меню Еще — Изменить форму непосредственно в режиме предприятия или сохраним типовые настройки формы для пользователей с помощью механизма администрирования настроек.