Dephi стирает {$IFDEF}

← →
BFG9k © (2005-10-13 14:47) [0]

Создаю пакет, в его коде пишу :

uses Unit2,Unit3, {$IFDEF XXX} Unit1 in "PAS\Unit1.pas" {$ENDIF} ;

После компиляции иногда {$IFDEF XXX} исчезает.

Вопрос: почему дельфи лазит своими грязными лапами в моих исходниках и как это отключить ?

← →
Digitman © (2005-10-13 14:51) [1]

а куда столько опер.систем-то налепил в теме вопроса ?)

они ж не виноваты)

← →
BFG9k © (2005-10-13 15:03) [2]

Я так всегда делаю, подразумевая, что программа должна работать под всеми этими ОС. И если у кого-то стоит Win98, он все равно может ответить на мой вопрос, хотя у меня Win 2000.

Если вопрос по Indy компонентам, я естественно не буду включать ранние версии Delphi. Здесь вопрос общий.

Дополнение: {$IFDEF} стирается не после компиляции, а после того, как меняешь что-либо в опциях проекта.

← →
Reindeer Moss Eater © (2005-10-13 15:26) [3]

Вопрос: почему дельфи лазит своими грязными лапами в моих исходниках и как это отключить ?

Среда не любит когда своими грязными лапами ты правишь dpr.
Это давно известная фича.
Используй *.pas

← →
Гаврила © (2005-10-13 15:31) [4]

Я бы не сказал, что это фича

← →
Lexer © (2005-10-13 15:32) [5]

Скорее всего это глюк твоеё версии Delphi, у меня всё ok.
Кстати, если приведенный кусвок кода вырезан из программы, то он не рабочий. Что если дефайн рачен XXX?
переделай на это:
uses Unit2,Unit3 {$IFDEF XXX} , Unit1 in "PAS\Unit1.pas" {$ENDIF} ;

← →
Reindeer Moss Eater © (2005-10-13 15:34) [6]

Повторюсь.
Это давно известная фича.

← →
Digitman © (2005-10-13 15:34) [7]

> программа должна работать под всеми этими ОС

да до программы-то еще и дело не дошло !)

ее ж еще скомпилировать неплохо было бы, перед тем как рассуждать о ее потенциальной работоспособности на той или иной платформе) .. а у тебя до компиляции еще и дело даже не дошло)

> Дополнение: {$IFDEF} стирается не после компиляции, а после
> того, как меняешь что-либо в опциях проекта

существенное, кстати, дополнение.
и это нормальная реакция среды.

ты же не удивляешься, что при манипуляции тобой в опциях проекта списком Auto-create Forms в dpr проекта волшебным образом появляются и исчезают строчки вида Application.CreateForm(..) ?

это "волшебство" ты воспринимаешь как вполне нормальное, ожидаемое и никак тебе не мешающее (скорее - помогающее), так почему же тебя раздражает то же "волшебство", но чуть выше по тексту dpr ?

← →
Digitman © (2005-10-13 15:38) [8]

> BFG9k

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

← →
BFG9k © (2005-10-13 15:39) [9]

Lexer :

То же самое.

Насчет внесения запятой в {$IFDEF} : я так сделал намеренно. Если я забуду указать define - компилятор ругнется.

Reindeer Moss Eater:

Я немного ошибся в описании. Это не dpr, а dpk (пакет). Там не uses, а contains. Как я могу сделать то же самое, используя pas-файл ?

← →
Reindeer Moss Eater © (2005-10-13 15:46) [10]

Как я могу сделать то же самое, используя pas-файл ?

способ номер один:
- оставить все как есть, но пакет собирать из командной строки и не открывать его в ide.

способ номер два:
-вставить в dpk {$I myuses.inc} и все шаманство с uses сделать в inc

способ номер три:
-в контейнс пакета оставить один файл, и в этом файле мудрить с uses (будет предупреждение компилятора, о том что модули импортированы в пакет неявно)

← →
Reindeer Moss Eater © (2005-10-13 15:51) [11]

Сам я предпочитаю первый способ.
При этом средой не создается файл мой_пакет.cfg который влияет на используемые директории.
Все нужные каталоги и опции я задаю в командной строке dcc32.

← →
BFG9k © (2005-10-13 15:56) [12]

Digitman:

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

Это пакет. Поставил перед собой следующую задачу. Нужно сформировать несколько пакетов с похожей структурой, но включающие в себя разные модули. Структура описывается в одном файле (чтоб 10 раз не переписывать). В нем, а также в dpk, с помощью директив условной компиляции описывается, какие юниты подключать в зависимости от define.

← →
Reindeer Moss Eater © (2005-10-13 16:01) [13]

Поставил перед собой следующую задачу. Нужно сформировать несколько пакетов с похожей структурой, но включающие в себя разные модули.

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

← →
BFG9k © (2005-10-13 16:01) [14]

Reindeer Moss Eater:

Кажется способы 2 и 3 - это то, что мне нужно (особенно 2).

Способ №1 не подходит - я использую Search Path и т.д.

Спасибо за ответы без демагогии (к начинающим меня) ;-)

← →
Digitman © (2005-10-13 16:02) [15]

> BFG9k © (13.10.05 15:56) [12]

> Пускай все "волшебным образом" появляется, до тех пор пока
> это реализованно корректно

здесь в корректности, надеюсь, нет сомнения ?

> "Волшебным образом" что-то должно исчезать, если

с какого перепугу-то это самое "если" ?

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

>Способ №1 не подходит - я использую Search Path и т.д.

Способ №1 подходит точно так же как и все остальные.

Reindeer Moss Eater:

Почему это ? Имена тоже будут разные. Правда придется вводить их вручную. Можно ли и имя пакета определять с помощью IFDEF ?

Ну и чем эта чудная инженерская мысль лучше нескольких dpk?

dpk и еще один основной модуль. Они одинаковые для всех пакетов за исключением небольших различий, которые я хочу описать при помощи условной компиляции. При необходимости изменить структуру модуля мне нужно изменять 10 dpk с 10 основными модулями для 10 пакетов.

Еще можно унаследовать эти 10 модулей от одного основного. Но я посчитал, что нет нужды с этим возиться, так как структура модуля относительна простая.

Хотя можно сделать 10 dpk и один основной модуль, в котором и возиться с условной компиляцией. Видимо это имелось в виду...

При необходимости изменить структуру модуля мне нужно изменять 10 dpk с 10 основными модулями для 10 пакетов.

Пакеты создаются один раз после чего оставляются в покое на тысячу лет.
Вся последующая правка происходит в одном модуле в одном месте один раз.

Впрочем что это я распыляюсь, давкай себе Ctrl F9 и шуруй переименовывать все свои 10 bpl по десять раз при каждой правке.

Удачи в благородном мартышкином труде!

Угу, осознал.

Dephi стирает {$IFDEF} Найти похожие ветки