Всем привет!
Заметил такую ошибку:

Старая конфигурация. УТ 10, обычные формы.
Новая платформа 8.3.26.1540 / 8.3.26.1498


Если работать по алгоритму обновления:

1) Запуск сравнения объединения
2) Детальное сравнение формы объекта
(проваливаемся внутрь модуля формы, сравниваем
процедура и тд.)
3) Подтверждаем сравнением. Обновляем бочку.

В таком случае форма ломается от слова совсем, могут появляться новые реквизиты формы, изменяться существующие
(положение реквизитов формы, содержание табличного документа на форме).

Выявил лечение: полный перенос формы без детального сравнения модуля.

Было ли у кого подобное? Сам вижу в первый раз.

я 26-ую ветку пропустил, на 27-ой не наблюдаю.

(0) УПП, всё гладко на 25 и 27

(0) На 25 такое было? Я пока пропустил 26-27, кроме как на домашнем компе.

(0) Баги сравнения-объединения "Схема не зарегистрирована" происходит от того, что некоторые макеты не открываются с той же ошибкой. Ошибка есть на багтрекере, исправление непонятно когда

(3) До этого использовалась прямо совсем старая. Точную версию не подскажу, но прямо олдовая)


(4) А что за "схема не зарегистрирована"? Не сталкивался с таким. upd: Погуглил - точно не встречал.

После обновления "ломается" обычная форма? Было.
У меня старая база данных УПП, которая "пережила" неоднократное обновление конфигурации и платформы. Сейчас уже не помню когда, но после очередного обновления платформы начали массово выползать глюки предыдущих обновлений конфигурации.

На некоторых формах (в т.ч. типовых без изменений) присутствовали многократно "задублированные" некоторые элементы формы. Это могли быть рамки, надписи, поля ввода и т.д. (например, "Контрагент", "Контрагент1", "Контрагент2"...). Они "мирно" существовали, множились и размножались, внешне никак не проявляясь и не привлекая внимания программиста до тех пор, пока не ломали форму...

Простое самотестирование: в конфигуратор встать на первый элемент формы и клавишей переходить на следующий элемент. Как только курсор сделает "шаг на месте" - смотреть в свойствах наименование. И если оно с "номером" - форму глазками и ручками придётся сравнивать с типовой формой из конфигурации поставщика. Дело в том, что разработчики особо не заморачивались с наименованиями и наличие номера в наименовании далеко не контрафакт.

(6) У меня было конкретно что на форме (обычной) есть
    1 - Элемент формы (поле ввода) под названием
    "НазваниеПоля_Статистика" (условное название)
    2 - Реквизит формы (строка) под названием "НазваниеПоля".
    У элемента "1" в свойстве "Данные" выбран реквизит "2".

После такого некорректного объединения появился реквизит формы (строка) под названием "НазваниеПоля_Статистика", и у элемента "1" в свойстве "Данные" встал этот новый реквизит. Из-за чего сломалась логика выполнения алгоритмов формы.

P.S.
"С типовой формой поставщика" - документ полностью кастомный.

(6) А как решили в итоге? Смирились, или откатились?

(8) Написал обработку, которая строила дерево, подобное списку элементов управления, а на нём выделял те элементы, у которых совпадали значения координат элементов (Лево/Верх/Ширина/Высота). Этого оказалось достаточно чтобы быстро отловить все глюки предыдущих обновлений и свести волну "битых" форм на нет.

Уже с обычными формами не работаю. Не было.