2009-04-16 3 views
5

Всякий раз, когда вы добавляете новое устройство в проект, Delphi восстанавливает файл .dpr, и все IFDEF в разделе uses исчезли.Как вы относитесь к IFDEF в .dpr, используйте раздел

Чтобы обойти это, я обычно использую NotePad для создания новых .pas-файлов и добавляю их в .dpr вручную. Если мне нужна форма, я использую File-> New-> Form, а затем верните файл .dpr в предыдущую версию. Не очень РАД, если вы спросите меня ;-)

Как вы справляетесь с этим? Есть ли способ добавить единицу в среду IDE, сохраняя IFDEF?

+0

Не могли бы вы объяснить, почему вы только _sometimes_ хотите единица быть участником вашего проекта? Я не понимаю цели. –

+4

В нашем проекте мы используем FastMM, который поставляется с Delphi для сборки релизов, но внешний FastMM4.pas для отладки. Итак, у нас есть IFDEF вокруг «использует FastMM4;» –

+0

@Ulrich: Я использую FastMM4 для сборки DEBUG и RELEASE - почему бы и нет? Это часть репозитория SVN проекта, и я получаю одну и ту же среду независимо от версии компилятора. Что не нравится? – mghie

ответ

2

Вы можете добавить его вручную в IDE. (Используйте параметр «источник просмотра» в проекте).

Обычно dpr является «скрытым». Вы не должны ничего менять. И если вы это сделаете, вы должны убедиться, что все ваши изменения ручны, иначе вы теряете некоторую информацию.

9

Иногда я создаю единицу как место для всех IFDEF и других вещей, которые IDE будет испортить, если они были в dpr. Этот блок обычно находится в верхней части предложения использования dpr. Этот трюк не подходит для всех сценариев, но иногда он экономит много утомительной работы.

+0

+1. Я не помню, чтобы когда-либо использовалось условное включение единиц. Зачем это делать? – mghie

+1

@mghie: переносимость через версии компилятора и RTL. Переносимость между компиляторами (Delphi vs. C++ Builder.) Избегайте включения модулей в зависимости от конфигурации сборки (например, вы можете не использовать поддержку дампа в выпуске, так как нет отладочных символов.) И еще сто сценариев. –

+0

в первую очередь это не приведет к тому, что условно включенные единицы станут частью проекта (и, таким образом, будут доступны через Project Manager) –

3

я провел некоторое время, пытаясь работать, что один из,

Я в конечном итоге есть файл проекта (.dpr) для каждого типа сборки, с условиями в проекте | Параметры проекта | Справочники/условных конструкций и лишь единицы я хотел добавил в к проекту

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

Как отметил Роб Кеннеди, это может быть выполнено путем помещения пользовательского кода в его собственный блок, который вызывается одной процедурой. таким образом, минимизируя размер/изменения кода .dpr.

Кроме того, еще один бонус, который вы получаете, заключается в том, что если вы добавите все ваши файлы .dpr в группу проектов, вы можете создать все ваши разные версии одним щелчком мыши/cmd line

+1

Большинство DPR-кода можно свести к минимуму, переместив их на другой блок, а затем получив одну строчку, вызывающую его. Таким образом, код DPR вряд ли когда-либо изменится. –

+0

благодарю за это, я обновил свой ответ, и я ухожу, чтобы обновить свой код;) –

3

Я не помещаю никаких ifdefs в файл dpr. Если я хочу использовать разные единицы/формы в проекте, в зависимости от какого-то условия, я разделяю проект на два.

0

(Delphi 7)

Я только попробовал то же самое. Взгляните на первую версию кода, и в моих комментариях ниже:

program Project1; 

{$IFDEF TESTIFDEF} 
uses 
    Forms, 
    Unit1 in 'Unit1.pas' {Form1}, 
    Unit2 in 'Unit2.pas' {Form2}; 

{$ELSE} 
uses 
    Forms, 
    Unit1 in 'Unit1.pas' {Form1}; 
{$ENDIF TESTIFDEF} 

{$R *.res} 

begin 
    Application.Initialize; 
    Application.CreateForm(TForm1, Form1); 
    Application.CreateForm(TForm2, Form2); 
    Application.Run; 
end. 

В тот момент, я только вставил 2-ю форму и заметил, что соответствующий блок (unit2.pas) был вставлен в первый часть IFDEF, то есть внутри маркированной части «TESTIFDEF», следовательно, не перекрывая второй блок (после {$ ELSE}).

Таким образом, ваше решение должно быть:

  1. определяют заявление IfDef как "{$ IFDEF DELPHIBASISCONFIGURATION}" вместо моего "{$ IFDEF TESTIFDEF}", где будут добавлены все формы.
  2. определите как можно больше альтернативных LABELS для различных конфигураций, с которыми вы хотите работать.
  3. каждый раз, когда вы добавили форму в проект, скопируйте вставленную строку первого блока в соответствующие блоки ниже - в зависимости от ваших потребностей ...
  4. активировать требуемую конфигурацию с помощью инструкции define или опции диалог
  5. нИКОГДА нЕ ОПРЕДЕЛИТЬ «DELPHIBASISCONFIGURATION»;)

Следовательно, он должен выглядеть следующим образом:

program Project1; 

{$DEFINE MYCONFIG1} // THIS ONE IS NOW ACTIVE 


{$IFDEF DELPHIBASISCONFIGURATION} 
uses 
    Forms, 
    Unit1 in 'Unit1.pas' {Form1}, 
    Unit2 in 'Unit2.pas' {Form2}, 
    Unit3 in 'Unit3.pas' {Form3}; 

{$ELSE} 
    // THIS IS A "COMMON TO ALL CONFIG" PART 
    uses 
     Forms, 

     // FIRST CONFIGURATION 
     {$IFDEF MYCONFIG1} 
     Unit1 in 'Unit1.pas' {Form1}, 
     Unit3 in 'Unit3.pas' {Form3} 
     {$ENDIF MYCONFIG1} 

     // SECOND CONFIGURATION  
     {$IFDEF MYCONFIG2} 
     Unit1 in 'Unit1.pas' {Form1}, 
     Unit2 in 'Unit2.pas' {Form2} 
     {$ENDIF MYCONFIG2} 

    // THIS IS THE "COMMON TO ALL CONFIG" END :) 
    ; 

{$ENDIF TESTIFDEF} 

{$R *.res} 

begin 
    Application.Initialize; 
    Application.CreateForm(TForm1, Form1); 
    //Application.CreateForm(TForm3, Form3); 
    //Application.CreateForm(TForm2, Form2); 
    Application.Run; 
end. 

Как вы можете видеть, я отбрасываются вызовы приме cation.CreateForm (...) для Form2 и Form3.

ИМХО, обычно лучше динамически создавать дополнительные формы в момент, когда вы действительно нуждаетесь в них то есть не все формы при старте программы ...

+1

Это очень умная идея. К сожалению, он не работает с D2007, который, по-видимому, понимает определения и изменяет «реальный» раздел :-( – Giel

1

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

1) Создайте новый блок, который содержит либо родительский для всех других классов, либо интерфейсы, которые все они будут реализовывать (я обычно предпочитаю более поздний, поскольку он позволяет упростить настройку) [например, это называется uSpecialParent.pas]

2) Добавьте переменную класса, на которую будут ссылаться, когда вам нужно создать новую функциональность. Например, если вы только собирались показать модальную кучу форм, так и не заботиться о каких-либо других методах, то вы могли бы иметь переменный, которая выглядела так:

TYPE 
    TMySpecialFormClass : class of TForm; 

VAR 
    TMySpecialForm : TMySpecialFormClass; 

3) Создайте еще один блок, который будет содержат все IFDEFS. Это может выглядеть примерно так:

Unit uRegisterSpecialForms; 

interface 

uses 
{$IFDF SPECIAL1} 
    uSpecial1, 
{$ENDIF} 
{$IFDEF SPECIAL2} 
    uSpecial2, 
{$ENDIF} 
    uSpecialParent; 

implementation 

// no code needed. 

initialization 

{$IFDEF SPECIAL1} 
    TMySpecialForm := uSpecial1.TSpecialForm1; 
{$ENDIF} 
{$IFDEF SPECIAL2} 
    TMySpecialForm := uSpecial2.TSPecialForm2; 
{$ENDIF} 

end. 

4) Для того, чтобы ссылаться на это в своем коде вы только нуждаетесь в uSpecialParent добавляется в блок, который будет запрашивающей специальную форму, а затем создать его динамически, например, чтобы показать эту модальность вы можете вызвать следующее:

var 
    frm : TForm; 
begin 
    frm := TMySpecialForm.Create(nil); 
    try 
    frm.showmodal; 
    finally 
    frm.free; 
    end; 
end; 
1

И вот вот-технический подход к полноте ради:

После того, как IDE испортило ваш пункт польз снова:

  1. закрыть проект
  2. перейти к инструменту управления версий выбора и дифф ДПР против последней зарегистрированного в версии с помощью слияния с поддержкой инструмента сравнения, как WinMerge
  3. Возвратить IDE изменяет
  4. сохранить ДПР
  5. покончим с этим
Смежные вопросы