Есть ли способ запретить компилятору VB6 перетасовать содержимое файлов?
По неизвестным причинам компилятор VB6 часто любит переупорядочивать содержимое файлов .vbp и блок дескриптора элемента управления в верхней части файлов .frm (код, описывающий свойства элементов управления в форме. Код, который вы не видите в IDE, но вы видите в текстовом редакторе и при выполнении различий с предыдущей ревизией в системе контроля версий.). Это чрезвычайно раздражает и очень отвлекает при сравнении версий файла.
Есть ли способ предотвратить это?
Я делал это раньше в формах, когда мне нужно было вставить новые вкладки в существующий элемент управления SSTab между двумя другими вкладками, что было проще, чем добавлять новые вкладки в конец, а затем вручную вырезать / вставлять между вкладками, чтобы все было правильно . Пока вы будете осторожны, вы можете заставить его работать ;-)
Тег annoyances заменен на annoyance.
Частичный дубликат stackoverflow.com/questions/1511302/…. Мы разработали сценарий ловушки для контроля версий, который переупорядочивает файл .vbp перед фиксацией. stackoverflow.com/a/16844710/1073262 Не хватило смелости взяться за файлы .frm.
Ответы 3
Можно ли сделать файл .vbp доступным только для чтения, если вы его не редактируете (например, не добавляете модули и т. д.)?
Что касается файлов форм ... Я не могу придумать никакого хорошего способа заставить VB не переупорядочивать их. Но должен сказать, что никогда раньше с этим не сталкивался. Вы уверены, что чего-то еще не происходит?
Вполне возможно, что я просто никогда не обращал на это внимания в прошлом, поэтому я не говорю, что вы ошибаетесь, а просто предлагаю свои собственные наблюдения.
Не думаю, что с этим можно что-то сделать. Я заметил ту же проблему: IDE любит переставлять вещи, казалось бы, без видимых причин. Некоторые вещи, которые я заметил:
Когда вы используете элемент управления SSTab, VB любит переупорядочивать свойства для вкладки, особенно TabEnabled имущество.
Для файлов проекта случайным образом изменяет порядок, в котором файлы появляются, и я думаю, что помню, как случаи, когда похожие типы файлов не всегда сгруппированы и заканчиваются смешанный с проектом характеристики. У тебя нет большой контроль над этим, если вы не запускаете все свои VBP через какой-либо тип дезинфицирующего средства, которое группирует файлы вместе (формы в одной группе, модули в другой группе и т. д.) и сортирует их в алфавитном порядке или что-то в этом роде, чтобы они оставались согласованными. Один из возможных способов справиться с этим может заключаться в написании надстройки IDE, которая автоматически делает это каждый раз, когда вы сохраняете изменения в файле проекта, или придумываете некоторый пакетный процесс, который будет просто рекурсивно проходить по вашим исходным каталогам и очищать все VBP в один раз.
IDE, кажется, случайно меняет футляр с вещами; это, кажется, происходит часто к ссылкам на проекты. Иногда они выводятся в нижнем случае, а в других случаях они вывод в верхнем регистре. Ты можешь получить вокруг этого, выбрав "Игнорировать Case "когда вы сравниваете файлы в SourceSafe.
Координаты управления, например Сверху, слева, по высоте и ширине могут различаться две ревизии одинаковой формы. Это до разным разработчикам, использующим разные разрешения экрана и / или разные настройки разрешения экрана при работе с одной и той же формой. Если вы этого еще не делаете, я очень рекомендую вам получить каждый разрабатывать то же самое разрешение и та же настройка DPI. Разные значения вызваны ошибками округления, которые возникают, когда логический экран координаты при разных разрешениях / настройках DPI конвертируются в твипы, по умолчанию координатное пространство, которое VB использует для выкладывание форм. Кроме того, пока я в теме, сделайте убедитесь, что у всех установлено разрешение 96 точек на дюйм, потому что если вы разрабатываете формы VB на 120dpi, есть действительно хорошее шанс, что они не будут отображаться правильно на экране с разрешением 96 точек на дюйм.
Наверное, есть и другие вещи, которые я не могу вспомнить прямо сейчас ...
Что касается порядка изменения элементов управления в файлах формы, это нормально, и вы обычно не хотите пытаться изменить порядок элементов управления вручную, если он меняется от одной ревизии формы к другой. Порядок отображения элементов управления в файле формы определяет их Z-порядок в форме. Если порядок элементов управления изменится в файле .frm, это изменит их относительный Z-порядок в форме, что может привести к непредвиденным результатам в отображении ваших форм.
Порядок управления формой напрямую определяется Z-порядком. Изменить порядок файла проекта можно также путем закрытия, повторного открытия и сохранения проекта. Он предпочитает, чтобы документы и файлы ресурсов находились в конце. файлов с параметрами сборки.
Я заметил, что повторное открытие формы и повторное сохранение часто восстанавливают постоянный порядок.
это напоминает мне об ужасной проблеме времени компиляции, которая у нас была с большим приложением VB6 ... в основном кто-то переупорядочил элементы в настраиваемом файле управления пользователем .ctl, и скомпилированный начал с каким-то совершенно несвязанным сообщением. Это сработало, когда мы откатились в VSS, поэтому мы просто вернули его, как было!