Есть предположение, что начинал создавать базовый проект на одной машине, продолжил на другой.
Видимо так.
Теперь бы понять почему это произошло.
В том числе и потому, что мы все мало внимания уделяли путям замещения.
Коллеги, я оформлением не занимаюсь, мне как лесоустроителю это не нужно ни в лесу ни для работы с аналитикой. Поэтому я сейчас попытался вникнуть в Ваши дела по сути только сейчас, т.к. задолго до выхода 9-ки мы уже не занимались производственной деятельностью и повода интерсесоваться у меня не было. Возможно, что я еще не до конца что то понял, но серия экспериментов, которые я провел за эту неделю привели меня к следующим выводам.
Использовать в Ваших проектах абсолютные пути (типа D:\...) нельзя и нужно менять все на "пути замещения" по следующим причинам.
Логика работы Тополя с библиотеками и макросами получается такая.
Приоритетом является реестр, настраиваемый через "Инструменты - Настройка - Пути замещения". Для возможности использования этих путей самостоятельно друг от друга мы добавили две переменных - путь к библиотеке и путь к макросам ТоПас. Сейчас они формируются при установке версии 834 и Д.А. сделал возможность при загрузке выбирать эти пути.
Но это работает только если в проекте все эти пути прописаны, например:
НЕ <Expression Name="" Expression="CalcValue('D:\LesIS\_Les\ToPas\HighlightKvrV.tps')" ID="53"/>
А <Expression Name="" Expression="CalcValue('|_ToPasFolder|\HighlightKvrV.tps')" ID="53"/>
потому, что через реестр это не правится. Импортом тоже.
Тополь сам пути в проекте не правит даже в разделе их определения. Когда я написал, что у меня получилось - это был оптический обман уставшего человека... ))) Он берет путь прямо из проекта если он абсолютный и путь замещения из реестра когда он там определен и из проекта если его в реестре нет.
Посмотрел Ваши проекты:
- В них пути замещения перемежаются с абсолютными адресами.
- Кроме того, абсолютные ссылки тоже иногда смешанные - с разных дисков.
- В путях замещения есть разнобой и несоответствие их назначению. Например, путь к библиотеке в одном случае |_LibraryFolder|, в другом |_ProjectFolder|, в третьем - |_WorkingDirectory|...
Сами понимаете, что при таком подходе воспользоваться в полной мере наработками Сергея Николаевича Городничева в оформлении карт не получится.
Теперь о том, что можно сделать.
1. Если ничего не делать, то придется взять его проекты один в один и всем восстанавливать его среду с дисками и путями. Кому то это вообще не доступно будет. Не у всех есть сеть... не у всех есть другой диск кроме C: и не все захотят возиться с подстановкой каталогов вместо сетевого диска.
2. Импортом проекта это не лечится. Может я не так что то делал, попробуйте и если получится опишите. Цель, чтобы в Ваших проектах массово заменились пути на нужные Вам, а для корректного результата - на пути замещения.
3. Один из реальных вариантов - заменить в текстах все пути на корректные. Я могу описать эту процедуру, но она действительно потребует освоения двух реально полезных для таких целей инструментов. Я в них полностью меняю оформление и дизайн всего нашего сайта из нескольких сотен страниц примерно за час не ломая содержимого. Однако, это лишь переведет Ваши проекты на пути замещения, но полезные наработки от Городничева к Вам не попадут.
4. Можно, также, заменить содержимое своих проектов целиком блоками обращения к библиотекам и макросам. Это ручная работа в текстовом редакторе.
5. Можно пойти более привычным путем - взять за основу проект из 834 версии с поправленными путями и для каждого своего перезагрузить туда заново набор данных. Но это касается рабочих (текущих) и оформительских проектов, где открыто много других блоков... растров... Так как штатный проект для пользовательской работы с базами самодостаточен и нам, например, хватает одного проекта на весь рабочий каталог.
И еще один неприятный момент для тех случаев если Вы работаете с альтернативным размещением проектов, библиотек и макросов - чистый Тополь открытый с каким то другим проектом может переписать реестр если Вы работая в этом проекте в Инструменты - Настройки переопределите путь к библиотеке или макросам. Теоретически Вы этого не должны делать, поскольку там этих библиотек не было, но мы должны исходить из худшего - есть категория пользователей, которая если видит какую то возможность, то обязательно ее попробует пощупать... )) Но, как минимум, при обращении из чистого тополя при альтернативном размещении в реестре изменится путь к проекту и тогда при запуске TopoL-L2 Вы увидите нестандартный каталог с проектами. При выборе штатного размещения этого не происходит т.к. Д.А. обработал эту ситуацию. Эту тоже обработает, но пока будьте внимательнее.
Так что, мой совет - забыть про категоричность и подумать над способами решения этой проблемы на пути стандартизации задач оформления. )
Если мы это сделаем то последующий обмен технологиями оформления и печати сильно упростится и не будет зависеть от конкретных настроек источника и приемника.
Я со своей стороны попробую поработать с присланными мне проектами и найти наиболее простой путь замены информации в них в качестве образца.