так он есть... я весь ехе со старого випера (5440) положил в бин нового... и указал в проекте путь на него
старый випер ФР собирал на ура. новый не хочет
нужно вынести в настройки VIPER, отсутствие этого прото бесит .. сейчас патчи прошли .. пипец все проекты править ... везеде пересчеты настроек .. а ... забыл испрвить тут .. капец ..:
1)база данных
2)лицензия (собственно необходимо объединить лицензию и БД (п.1))
3)Отладчик VIP
4)глобальные переменные
Bender, а может быть проблема в том что fr.prj сам по себе пустой, а в его настройках стоит галочка указывающая паковать из определенного каталога fr отчеты. Может сейчас так нельзя делать? хотя раньше работало.
попробовал в настройках *.prj файла в пункте FR указать собирать FR формы, указал каталог. Всё равно не работает. Строчником опять собрал.
Алексей писал(а):Bender, а может быть проблема в том что fr.prj сам по себе пустой, а в его настройках стоит галочка указывающая паковать из определенного каталога fr отчеты. Может сейчас так нельзя делать? хотя раньше работало.
попробовал в настройках *.prj файла в пункте FR указать собирать FR формы, указал каталог. Всё равно не работает. Строчником опять собрал.
сложилось ощущение что випер запомнил первый файл с таким именем и всегда собирает его и только его... галочку в настройках проекта "компилятор VIP - каталоги - Вести кэш файлов для поиска по спискам каталогов" я отключил, была включена, но это не помогло...
он упорно цепляет первый файл с именем, который нашел... что делать?
ещё одна: хоть и указана настройка куда складывать *.tmp файлы, он упорно кладет на каталог выше *.vpr проекта... немного но всё же кидает tmp и не чистит за собой. видимо где то tmp создаются без чтения настройки где создаваться.
сложилось ощущение что випер запомнил первый файл с таким именем и всегда собирает его и только его... галочку в настройках проекта "компилятор VIP - каталоги - Вести кэш файлов для поиска по спискам каталогов" я отключил, была включена, но это не помогло...
он упорно цепляет первый файл с именем, который нашел... что делать?
Help!!! я один, у кого названия файлов иногда повторяются?! не могу пересобрать проект, находит первый user_rep.vip и все... другие уже не компилирует!!! не руками же их собирать, я уже привык к "пакетному режиму" !
Алексей.
Скорее всего проблема в путях, которые указаны в параметрах компилятора "Пути для поиска подключаемых файлов". Во время компиляции атлантис ищет подключаемый файл по этим путям. Как только нагшел - так и использует его. Откуда ему знать что такой файл ему надо брать из какого-то другого каталога? Указывайте конкретные пути в настрйоках конкретных prj. Также советую использовать не make, а include.
в том то и проблема, что файлы user_rep.vip прописаны в *.prj проектах как #make "user_rep.vip", никаких инклюдов.
и даже если бы и были инклюды, разве компилятор не должен в первую очередь искать файл в каталоге проекта *.prj а уже потом по указанным директориям? это же логично.
что то перечитал ещё раз ваш ответ... т.е. в проекте *.prj вместо make надо написать просто #include user_rep.vip и компилятор его соберёт? попробую завтра.
а как быть если потом я захочу скомпилировать строчником, и випер будет недоступен (к примеру вы сделаете его платным ).
что то мне кажется не совсем верно так делать. в проекте указано какие файлы надо собрать... он лежит в этом же каталге, галочка про "кэширование путей на файлы" снята... должно всё работать.
Так оно и есть, в начало коллекции путей добавляется путь на prj, эта доработка доступна в Viper.exe начиная с версии 5.5.10.0.
Проверил на своем примере - есть два prj, в каждом из них подключаются одноименные файлы через make (которые валяются рядом с соответствующими prj).
Кстати, как раз include и ищет файла в коллекции путей, а make вроде (не уверен..надо смотреть код) берет от текущей директории.
ну так у меня в проектах #make, почему он пытается собрать другой файл, который встретил ранее? кстати, при его компиляции было предупреждение, может это заставляет его "запомнить" ? в любом случае, имхо, это ошибка. я же давно на viper собираю проекты, не было такого раньше.