¿Cómo lidiar con IFDEF en .dpr utiliza la sección

Question

Cada vez que agrega una nueva unidad al proyecto, Delphi reconstruye el archivo .dpr y todos los IFDEF en la sección de usos se han ido.

Para solucionar este problema, suelo usar NotePad para crear nuevos archivos .pas y agregarlo manualmente. Si necesito un formulario, utilizo File-> New-> Form y luego revertir el archivo .dpr a la versión anterior. No muy RAD si me preguntas ;-)

¿Cómo lidiar con eso? ¿Hay alguna manera de agregar una unidad en el IDE mientras se mantienen los IFDEF?

Answer 1

Puede agregarlo manualmente desde el IDE. (Use la opción "ver fuente" en el proyecto).

Normalmente, el dpr está "oculto". No se espera que cambies nada allí. Y si lo hace, es mejor que se asegure de que todos los cambios sean manuales, de lo contrario está perdiendo cierta información.

Answer 2

A veces creo una unidad específicamente como un lugar para todos los IFDEF y otras cosas que el IDE podría estropear si estuviera en el dpr. Esta unidad normalmente va a la parte superior de la cláusula de usos de dpr. Este truco no abarca todos los escenarios, pero a veces ahorra mucho trabajo tedioso.

Answer 3

pasé bastante tiempo tratando de trabajo que uno,

terminé tienen un archivo de proyecto (.dpr) para cada tipo de generación, con las condiciones en las Proyecto | Opciones del proyecto | Directorios/Condicionales y sólo las unidades que quería añadido en el proyecto

esta dosis tienen la desventaja de que si usted tiene un código personalizado en el .dpr, que tendrá que ser copiado manualmente a los otros archivos de proyecto cuando cambia.

según lo observado por Rob Kennedy, esto se puede manejar colocando el código personalizado en su propia unidad, que se llama mediante un único procedimiento. reduciendo así al mínimo el tamaño del código .dpr/cambios a realizar

Además, otra ventaja que se obtiene es que si se suman todos sus archivos .dpr a un grupo de proyecto, se puede construir todos sus diferentes versiones con un clic/línea de cmd

Answer 4

No coloque ningún ifdefs en un archivo dpr. Si deseo usar diferentes unidades/formularios en un proyecto, dependiendo de alguna condición, divido el proyecto en dos.

Answer 5

(Delphi 7)

he acaba de intentar lo mismo. Tome un vistazo a la primera versión de código y en mis comentarios a continuación:

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. 

En ese momento, acabo de insertar el segundo formulario y se dio cuenta de que la unidad correspondiente (Unit2.pas) se insertó dentro de la primera parte del IFDEF, es decir, dentro de la parte etiquetada "TESTIFDEF" - por lo tanto, no anula el segundo bloque (después del {$ ELSE}).

lo tanto su solución debe ser:

1. definen una declaración IFDEF como "{$ IFDEF DELPHIBASISCONFIGURATION}" en lugar de mi "{$ IFDEF TESTIFDEF}" en el que se añaden todas las formas.
2. definen tantas ETIQUETAS alternativas para las diferentes configuraciones con las que desea trabajar.
3. cada vez que ha agregado un formulario al proyecto, copie la línea insertada del primer bloque en los bloques correspondientes a continuación - según sus necesidades ...
4. active la configuración requerida utilizando la instrucción define o la opción
de diálogo
5. NUNCA definen "DELPHIBASISCONFIGURATION";)

Por lo tanto, debe tener este aspecto:

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. 

como se puede ver, he descartado las llamadas a Appli cation.CreateForm (...) para Form2 y Form3.

en mi humilde opinión, por lo general es mejor crear dinámicamente las formas complementarias en el momento en que realmente los necesite es decir, no todas las formas de inicio del programa ...

Answer 6

Para las formas, Módulos de Datos y otras unidades que contienen una clase única por la cual se reemplazará la funcionalidad, la solución es bastante simple. Simplemente NO agregue las unidades personalizadas directamente al producto, pero guárdelas en algún lugar de la ruta de búsqueda (o modifique la ruta de búsqueda del proyecto para incluir su ubicación).

1) Cree una unidad NUEVA, que contenga el padre para todas las otras clases, o las interfaces que implementarán todas (generalmente prefiero la última ya que permite una personalización más fácil) [por ejemplo, esto se llama uSpecialParent.pas]

2) Agregue una variable de clase a la que se hará referencia cuando necesite crear la nueva funcionalidad. por ejemplo, si sólo se va a mostrar modal de un montón de formas, así que no se preocupan por cualquier otro método, entonces usted podría tener una variable que se parecía a lo siguiente:

TYPE 
    TMySpecialFormClass : class of TForm; 

VAR 
    TMySpecialForm : TMySpecialFormClass; 

3) Crear otra unidad que se contiene todos los IFDEFS. Podría ser algo como lo siguiente:

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) Para hacer referencia a esto en su código sólo tiene que la uSpecialParent añadió al bloque que se solicita una forma especial y luego crear de forma dinámica, por ejemplo, para mostrar este modal usted podría invocar el siguiente:

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

Answer 7

y aquí está el enfoque lo-tech para dar información completa:

Después de que el IDE ha ensuciado su cláusula uses de nuevo:

1. cerrar el proyecto
2. ir a su herramienta de control de versiones de elección y Diff la DPR contra la última versión protegida utilizando una herramienta de diferencias de combinación habilitado como WinMerge
3. revertir el IDE cambia
4. Guardar DPR
5. seguir adelante con ella