привет Всем! Пытаюсь выяснить, является ли конфигурация ЗиК 77 типовой или нет. Запускаю рабочую базу в режиме конфигуратора, выбираю Конфигурация-Объединение конфигураций, затем указываю MD типовой ЗиК того же релиза. В итоге выходит дерево с измененными объектами конфигурации. Но дело в том, что изменены получаются Объект-Форма-Диалог. А изменений по сути никаких нет? С чем это связано? Как избавиться от этого глюка? Почему 1с показывает, что форма объекта изменена?

Не обращай внимания. у тебя типовая.

(1) Как не обращать внимания? Мне приходится все "плюсики" на измененных объектах щелкать, чтобы видеть, что изменен только диалог формы... вдруг там модуль формы задет или еще что...

(0) был такой глюк, когда элементы формы сдвигались чуть вверх, при открытии формы в разных релизах платформы (было замечено на 25 и 27 релизе)

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

(4) есть. Была в природе обработка, которая давала подробный отчет об изменениях, именно ей я и сверял комплексную семерку с типовой когда возникла такая необходимость

+(4) Обработку зовут DlgCompare.ert. Вот кусок из ее ридмишника:
DlgCompare.ert
Версия 1.0.0
Обработка анализирует диалоги форм двух мдшников и показывает изменения в них
в удобоваримом виде.

Для доступа к текстам форм используется ActiveMD.dll (Автор Павел Бычковяк)
Перед использованием её необходимо зарегистрировать
----
думаю, вводных достаточно

Эх.... кнопочка Отчет... полный в диалоге сравнения не помогает?

(7) для всех объектов это муторновато, особенно если комплексная. (6) рулит.

руль заключается в том, что семерка иногда при сравнении дает ложные срабатывания на диалогах, которые на самом деле не изменились. А в этой обработке есть возможность задавать погрешности реагирования.

Ему как бы не это надо :)
Он просто плюсик нажимать не хочет, а стандартные средства это позволяют.
А обработка конечно классная, я себе скачал на всякий случай. Правда не запускал еще, но теоретическая польза очевидна. Но  кстати тоже раньше эмпирическим методом пользовался, если нет других изменений кроме диалога, то значит ничего и не менялось :) Пока прокатывало.

в редких случаях изменения есть только в форме и они существенные (добавлены новые кнопочки, колонки табличных частей и форм списков)

(0) если хочешь убедиться в отсутствии изменений модуля запускай детальный отчет об изменении конфигурации

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

Такая проблема была, когда тема рабочего стола не совпадала с темой рабочего стола разработчиков :)
Когда занимался семеркой, то помнил, какая тема была у разрабов. Сохранял конфу в ней и потом делал сравнение конфигураций

(14)разве тема, а не разрешение рабочего стола?

(15)
Вроде тема. Я уже не помню :)

(11) "в редких случаях изменения есть только в форме и они существенные (добавлены новые кнопочки, колонки табличных частей и форм списков)"

Если кто-то добавил в 7ке изменения на форме и при этом не прокомментировал в тексте модуля, то работу такого "специалиста" можно затереть обновлением - не велика потеря ;)

(15) ИМХО, зависит от "высоты" в пикселах заголовка окна, т.е. не от разрешения, а именно от темы.

Раз пошла такая пьянка, может знает кто из-за чего получается такая вещь: берем конфигурацию и конфигурацию потомок с небольшими исправлениями в глобальном модуле (добавлено два блока по строк 20 в каждом). Начинаем сравнивать и начинается: различий штук 40, причем только два - различия (добавленные блоки), остальные это одинаковые строки, в основном КонецЕсли и подобные, иногда вообще пустые. Вот как этого избежать?

(19) думаю что стандартными средствами никак. Кривоватое у них сравнение.

Есть ещё gcomp + kdiff3 + скрипт для нивелирования сдвига в формах.  
Хотя, это наверное слишком сложно для 1Снега :))

емнип, такая проблема появлялась, когда конфигурацию сохраняли на windows XP со стандартной темой оформления (с закругленными углами окон), чтобы избежать нужно было использовать классическую схему оформления (как в Win98).

(17) Не всегда. Приведу пример:
На форме имеется кнопка "ОК". В формуле кнопки написано "ПоКнопкеОК()" И соответственно в модуле прописана процедура для этой кнопки.
Исправили формулу в кнопке на "#Записать?Провести?Закрыть". В модуле ничего не удаляли.
На форме изменения произошли и они существенны. В модуле нет никаких изменений......

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

// [*] VVP: изменена формула кнопки ОК на основной форме - ПоКнопкеОК ()

и никак иначе. Если этого не делается - значит, специалист, который делал правки, хреновый.

+ (23) и в общем-то я согласен, что документировать изменения в том или ином виде нужно обязательно. Не факт что это лучше всего делать именно таким образом, но как-либо делаться должно.

(23)
Да не существенно все это. Если только специально целью задаться, то можно организовать ситуацию, что изменилась только форма и все рухнуло. Обычно же так не делают. В случае с кнопкой например должна быть убрана и процедура (или закоменчена хотябы) или новые действия прописаны в самой процедуре.