Directories and Conditionals

[blaiselaborde]

Buenos días;

Tengo una Unidad de Delphi que se utiliza en dos aplicaciones diferentes. El problema está en que hay uns instrucción que llama a un Método de otra Unidad sólo para una aplicación, en la otra, no se necesita y por tanto, genera un error de compilación. Tengo entendido que puedo controlar estos textos con las Directivas de Compilación, sin embargo, no puedo definir con $DEFINE en la misma Unidad, porque se comparte para ambas aplicaciones.

Estuve leyendo el Hilo: http://www.clubdelphi.com/foros/showthread.php?t=76880 pero estoy utilizando Delphi XE7 y no me coincide lo que hago con la solución que se propone.

Alguien me puede dar una mano? . . . .

Muchas gracias.


{$IFDEF NOTMAIN}
Uses DMJBS, DMImages, OneWayAppointment, LoginUnit, Common, DataModule, Data, RequestData;//, Main;
{$ELSE}
Uses DMJBS, DMImages, OneWayAppointment, LoginUnit, Common, DataModule, Data, RequestData, Main;
{$ENDIF}

. . .

Procedure TForm.acViewAccountExecute(Sender: TObject);
Begin
Inherited;
{$IFDEF NOTMAIN}
{$ELSE}
If Not dsOutboundList.DataSet.IsEmpty then
Begin
FRM_Main.SearchforCust(dbgResults.Cells[4, dbgResults.Row]);
pRefresh;
End;
{$ENDIF}
End; // Proc

[bucanero]

Hola blaiselaborde

Una forma con la que puedes realizar de forma fácil lo que pretendes es definir un fichero de texto que por ejemplo llames config.inc y donde vas a definir la configuración personalizada para cada proyecto y se guarda en la misma carpeta del proyecto

En este fichero es en donde se define la directiva y su contenido es tan simple como añadir algo así para definir una directiva:

{$DEFINE NOTMAIN}

Ya en la unit donde vayas a usar las directivas condicionales cargas la configuración añadiendo antes del uses una llamada a la directiva {$i ...}

uses unitX;

{$i config.inc}

interface

uses ...
...
...
...
end.

y listo para usar las directivas condicionales.

En cuanto a tu código yo lo pondría de la siguiente forma:
para el uses:
Uses DMJBS, DMImages, OneWayAppointment, LoginUnit, Common, DataModule, Data, RequestData{$IFNDEF NOTMAIN} ,main{$ENDIF};

Y tu procedimiento también podría quedar así:

Procedure TForm.acViewAccountExecute(Sender: TObject);
Begin
Inherited;
{$IFNDEF NOTMAIN}
If Not dsOutboundList.DataSet.IsEmpty then
Begin
FRM_Main.SearchforCust(dbgResults.Cells[4, dbgResults.Row]);
pRefresh;
End;
{$ENDIF}
End; // Proc



Un saludo

[Lepe]

Es así, pero vaya forma de complicarse las cosas con llamar mal las cosas ¿se entiende? NO, igual que el código :D

Has negado la directiva de compilación y eso te conlleva negar todos los "ifdef", además tienes un sinsentido (al leer el código): "{$IFNDEF NOTMAIN} ,main{$ENDIF};"

o sea, que si no está definida el NOTMain, entonces incluyo la unidad main... uff... traduce tío, traduce...

Hazlo mejor al revés definiendo la directiva de compilación así:
{DEFINE MAIN}

y el código queda: "{$IFDEF MAIN} ,main{$ENDIF};"
que leído resulta: "Si está definida la directiva MAIN, entonces incluye la unidad main.pas";más legible ¿no?

Saludos y recordad, las prisas no son buenas consejeras jejeje!

[bucanero]

Ciertamente poniéndolo como dice LEPE, sea la forma a priori mas legible, hay no voy a entrar a discutir.

En cuanto a mi respuesta, me he ceñido a la definición que tenia originalmente blaiselaborde

Aunque en mi caso particular, la formula usada por blaiselaborde, es una formula bastante utilizada, pues la historia es que para mis proyectos casi todos utilizan unos módulos generales comunes y por defecto se van a usar siempre para casi todos los proyectos, sin necesidad de definir nada en el config.inc. Y solamente en alguno de los proyectos puntualmente y como excepción puede ser que no se usen o no sean necesarios alguno de esos módulos, entonces es solamente para ese proyecto en particular en donde se define las directivas NOACTIVO para los módulos que no deseo cargar.

Para mi por tanto, el inconveniente principal de la opción de LEPE, de definir los directivas como activas frente a definir los directivas como noactivas, es que para todos los proyectos necesitaría definir las directivas de todos los módulos que quiero cargar, y en la mayoría de las veces serian prácticamente todos, por lo que tendría que definir montones de directivas en cada proyecto, mientras que si decido definir los que no voy a cargar, solo son unos pocos proyectos, y solo unos pocos módulos, por lo que tengo que definir solo algunas pocas directivas de negación.

Y todo esto para obtener simplemente una condición que a priori es un poco mas legible, para mi caso, lo considero una complicación innecesaria.

Un saludo

[Neftali [Germán.Estévez]]

Una vez que ya te han comentado cosas sobre los DEFINE, yo te diría que este problema, aunque se soluciona tal y come te han comentado, creo que denota que estás realizando un mal diseño.

Que una determinada unidad, necesite del FormMain para ejecutar un método (y más una unidad que vas a compartir entre varios proyectos) te está indicando que seguramente algo no es correcto (aunque sea "solucionable" tal y como te han dicho).

Si se puede, ese procedimiento al que estás llamado debería estar fuera en una unit aparte, para poder llamarlo con parámetros cuando fuera necesario.

"Imagina que tienes un TEdit(edit1) en un formulario (form1), y al realizar un cambio en el Edit1, necesitamos ocultar otro componente (Edti2) del form1".

Lo que no hacemos en el TEdit es colocar un DEFINE que diga (aunque funcinaría):


{$IFDEF FORM1}
...
form1.Edit2.Visible := False;
...
{$ENDIF}



¿Cómo lo solventamos? Se añade al TEdit un evento OnChange, que captura el formulario que lo necesite.

Creo que en este caso (por lo poco que comentas) una solución un poco más correcta sería una similar.
Define en el segundo form un evento y lánzalo en lugar de la llamada:



type
...
private
...
// Este tipo o con los parámetros que necesites en tu caso
property OnEvento1:TNotifyEvent read FOnEvento1 write FOnEvento1;
...

end;


Procedure TForm.acViewAccountExecute(Sender: TObject);
Begin
Inherited;
{$IFNDEF NOTMAIN}
If Not dsOutboundList.DataSet.IsEmpty then
Begin

// ---FRM_Main.SearchforCust(dbgResults.Cells[4, dbgResults.Row]);

// levantamos el evento si está asignado...
if Assigned(OnEvento1) then begin
OnEvento1(Self);
end;

pRefresh;
End;
{$ENDIF}
End; // Proc


Desde el Main si es necesario, deberás asignar ese evento para capturarlo.