Newsgroup: it.comp.lang.delphi
Titolo: unit con lo stesso nome

Ciao a tutti.
La mia applicazione utilizza una unit che ha svariate versioni, a seconda 
del bisogno.
F:\Unit\V1\pippo.pas,
F:\Unit\V2\pippo.pas,
...
F:\Unit\Vn\pippo.pas .
Il file .dpr punta alla versione ch in quel momento deve usare e ne usa una 
sola.
Ora ho la necessità di implementare un convertitore tra versioni
e dovrei inserire nella clausola uses del main due unit: il problema è che 
hanno
tutte lo stesso nome.
C'è qualche soluzione senza dover rinominare i file e l'intestazione interna 
delle unit?
GRAZIE.

delle unit?
Se hai lo stesso nome delle unit, la faccenda si complica di brutto, perche'
non puoi distinguere quale unit ti serve se la metti nelle uses
ESEMPIO:
unit PIPPO;
interface
uses
  Windows, Messages, SysUtils, UNIT1;
quale unit1 verra' inclusa?
Non mi viene in mente un sistema al momento, ma potresti lavorare piu' di fino
creando una unica unit gigante che contenga tutte le versioni.
Cosi' facendo, la uses sarebbe sempre corretta puntando all'unica unit, e la
versione del tuo codice da utilizzare la potresti determinare con delle
direttive.
Ti faccio un esempio:
Nella unit gigantesca, metti le differenze tra versioni usando le direttive:
Function Tpippo.GetNumero : integer;
Begin
  i := -1;
  {$IFDEF V1} // compila con versione 1 della unit
      i := TMiaClasse.getInteger;
  {$ELSE}
  {$IFDEF VER2} // compila versione 2 della unit
      i := TAltraMiaClasse.getInteger;
  {$ELSE}
  {$IFDEF VER3} // compila usando versione 3 della unit
      i := 0;
  {$ENDIF}
  Result := i;
end;
Poi nella radice del tuo progetto, aggiungi un file di testo versione.inc che
contenga la versione con cui vuoi compilare.
{---------------------------------------------------------------------}
{----- Scelgo la versione da compilare: il punto disattiva la define -}
{---------------------------------------------------------------------}
{.$DEFINE V1} // Uso la versione 1 della unit, con il metodo MiaClasse
{.$DEFINE V2} // Uso la versione 2 della unit, con il metodo AtraMiaClasse
{$DEFINE V3} // Uso un altro metodo i := 0
Includi il file versione.inc nel progetto col classico 
{$R include.inc}
E lancia il build, dovresti cosi' riuscire a ricompilare ogni volta con la
versione che vuoi.
Sempre che le differenze tra una unit e l'altra si possano riassumere in un
unico file (e qui dipende dal contenuto, che non conosco)
Ciao!
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 F:\Unit\Vn\pippo.pas .
Se le due unit hanno la stessa interfaccia, una buona soluzione potrebbe 
essere quella di implementare una dll per ogni unit (oppure una unit la 
importi con la uses e l'altra la metti nella dll). In questo modo potrai 
gestire sia le varie versioni in modo piuttosto "pulito" e gestire le 
procedure duplicate semplicemente impostando nomi diversi nel codice di 
importazione.
Un'altra soluzione potrebbe essere quella di usare un pņ di compilazione 
condizionale.
Si tratta sostanzialmente di creare una terza unit nella quale includi le 
altre due, ma defininendo delle direttive condizionali
in modo da "nascondere" al compilatore i nomi duplicati.
Esempio:
unit pippo_union;
interface
    function f1_v1: boolean;
    function f2_v2; boolean;
implementation
{$DEFINE V1}
{$I ..\v1\pippo.pas}
{$UNDEF V1}
{$DEFINE V2}
{$I ..\v2\pippo.pas}
{$UNDEF}
...
nell'interface della unit "unione" metti la dichiarazione delle procedure 
con nomi diversi, mentre nell'implementazione includi i singoli sorgenti. 
Definendo prima delle clausole che utilizzi in seguito.
Ora, nelle singole unit devi "disabilitare" tutto il codice che indica al 
compilatore che questi file sono appunto delle unit autonome e fare in modo 
che vengano trattati come semplici file di testo:
per la unit ..\v1\pippo.pas:
{$IFNDEF V1}
unit pippo;
interface
    function f1: boolean
...
implementation
uses
    ...
{$ENDIF}
// cambi il nome della procedura, in relazione alla clausola definita
// questa operazione dovrą essere fatta per ogni procedura che
// si intende esportare
{$IFDEF V1}
function f1_v1: boolean;
{$ELSEIF}
function f1: boolean;
{$ENDIF}
begin
...
end;
{$IFNDEF V1}
end.
{$ENDIF}
e di conseguenza per la unit ..\v2\pippo.pas:
{$IFNDEF V2}
unit pippo;
interface
    function f1: boolean
...
implementation
uses
    ...
{$ENDIF}
// cambi il nome della procedura, in relazione alla clausola definita
{$IFDEF V2}
function f1_v2: boolean;
{$ELSEIF}
function f1: boolean;
{$ENDIF}
begin
...
end;
{$IFNDEF V2}
end.
{$ENDIF}
Ecco,... un pņ complicato ma dovrebbe funzionare...
Ciao,
Gianluca. 


------------------------
Diego Di Filippo
  R&amp;D Software Developer
 
www.ada-project.com
-----------------------
--- posted by geoForum on 
http://www.delphiedintorni.it

 uhmm!!! sono più d'accordo con l'opzione DLL!!!
:-D
... in effetti è una soluzione un pò complicata e contorta...
a mio avviso credo che la scelta dipenda dalla padronanza degli strumenti. 
Io personalmente, dovendo gestire personalizzazioni a volte anche piuttosto 
pesanti faccio un grande uso delle direttive di compilazione condizionale e 
di inclusione che mi consentono di centralizzare il codice senza 
necessariamente duplicarlo per ogni cliente o senza la necessità di 
implementare un sistema di gestione delle personalizzazioni "run-time" che 
per forza di cose inciderebbe negativemente sulle prestazioni.
Tornando al caso specifico del Thread, avendo un pò di dimestichezza con lo 
strumento, in una decina di minuti si risolve il problema, mentre 
l'implementazione di una DLL mi sembra un pò piu lunga e laboriosa... poi 
ovviamente ci metterei un bel pò di commenti, così la settimana prossima 
potrei comunque capire e ricordarmi cosa ho fatto :-)
Ciao,
Gianluca. 

la strada DLL sicuramente è la più laboriosa ma è anche sicuramente la 
più corretta!
Avendo dei moduli esterni si possono gestire le versioni non solo di 
alcne funzioni ma di un progetto intero! e poi mettendo direttive ovunque 
complicherebbe la leggibilità del codice!
A volte il cliente chiede delle tempistiche che portano a rovinare il 
progetto mettendo pezze veloci! in questo caso le unit vanno bene!
:)


Se vuoi anzichè utilizzare le DLL usa i package che ti permettono una
più semplice gestione degli oggetti...a meno che non vuoi utilizzare
le tue nuove DLL con altri software di sviluppo.