In Delphi XE2, abbiamo utilizzareDelphi XE2: Esiste un condizionale predefinito per identificare VCL e FireMonkey?
{$ifdef Win32}
{$ifdef Win64}
per identificare quale piattaforma ci troviamo.
C'è qualche condizionale predefinito che possono identificare VCL e FMX?
Come altri dicono, non esiste una direttiva condizionale per determinare se l'applicazione è VCL o FireMonkey. Penso che il modo più affidabile per determinare se la tua app è FireMonkey o VCL sta utilizzando una funzione anziché una direttiva condizionale.
Qualcosa di simile
Uses
Rtti;
function IsVCLApp:Boolean;
begin
Result:= CompareText(TRttiContext.Create.GetType(TApplication.ClassInfo).QualifiedName,'Vcl.Forms.TApplication')=0;
end;
function IsFireMonkeyApp:Boolean;
begin
Result:= CompareText(TRttiContext.Create.GetType(TApplication.ClassInfo).QualifiedName,'FMX.Forms.TApplication')=0;
end;
@Craig, ovviamente questo codice richiede quale unità di moduli deve essere aggiunta, riguardo l'ambito non è necessario aggiungere il "VCL". o "FMX". questo è risolto internamente da delphi. Quindi se usi 'Forms'or' Vcl.Forms' il codice funzionerà bene. E infine sul tuo ultimo commento che dipende dal tipo di applicazione, questa risposta suggerisce di usare una funzione come alternativa all'uso di una 'direttiva condizionale'. – RRUZ
Questo codice * richiede * che tu usi 'Forms' e non' Vcl.Forms'. Se usi esplicitamente 'Vcl.Forms' o' Fmx.Forms', hai già deciso sulla piattaforma nella clausola uses per l'unità, e quindi hai già un modo condizionale per controllare il widget widgetset di destinazione. –
Inoltre, poiché il TApplication a cui si fa riferimento non può essere modificato in fase di runtime, l'utilizzo di TRttiContext è ** completamente ** non necessario. Si potrebbe semplificare 'IsFireMonkeyApp' a' Risultato: = {$ IF DICHIARATO (TFmxObject)} True {$ ELSE} Falso {$ IFEND}; 'e avrebbe lo stesso identico comportamento. –
Non sembra esserci un compilatore definito in modo specifico per VCL/FireMonkey. Dovresti creare il tuo.
Un elenco di condizioni condizionali predefinite è disponibile nello documentation.
Il controllo della piattaforma non è affidabile, perché puoi creare ad esempio un'applicazione OSX con 'GUI senza Firemonkey' come mostrato qui http://stackoverflow.com/questions/7442131/delphi-xe2-is-it-possible-to-create-mac-gui-applications-without-firemonkey – RRUZ
@RRuz: abbastanza corretto. Modificato la mia risposta. –
Sebbene non documentato si può avere VCL e FireMonkey nella stessa applicazione.
Nessuna definizione del compilatore.
Se si sta creando qualcosa che deve essere sia VCL che Firemonkey, raccomanderei la separazione delle unità.
Un modo possibile:
miscelazione codice UI da due quadri differenti nella stessa unità non è una buona idea . Si collegherà nell'altra libreria quando non è necessaria.
+1 per 'separazione delle unità' – RRUZ
Abbrevia supporta sia la VCL e CLX utilizza questo tipo di scissione:
QAbUnit1.pas:
{$DEFINE UsingCLX}
unit QAbUnit1;
{$I AbUnit1.pas}
AbUnit1.pas:
{$IFNDEF UsingCLX}
{$DEFINE UsingVCL}
unit AbUnit1;
{$ENDIF}
type
...
TMyWidget = class({$IFDEF UsingVCL}TWinControl{$ENDIF}
{$IFDEF UsingCLX}TWidgetControl{$ENDIF})
...
end;
end.
Per aggiungere FireMonkey supporto, vorrei aggiungere un file come questo:
FmxAbUnit1.pas:
{$DEFINE UsingFMX}
unit FmxAbUnit1;
{$I AbUnit1.pas}
{$ENDIF}
e poi fare tutti i cambiamenti condizionale che ho bisogno di AbUnit1.pas.
Non è una divisione pulita come il suggerimento di Robert, ma il vantaggio è che tutte le modifiche si verificano in un singolo file e la definizione condizionale viene gestita automaticamente, quindi non è necessario che venga visualizzata nelle opzioni del progetto.Chiunque usi la tua biblioteca include solo l'unità appropriata per decidere quale utilizzare. Probabilmente potresti sfruttare anche l'ambito degli obiettivi, nominando i file Fmx.AbUnit1.pas e Vcl.AbUnit1.pas, ma penso che Embarcadero lo scoraggi.
Abbastanza bella soluzione. Ma l'intuizione di Help gestisce questa costruzione quando viene definita FMX? Almeno in XE2 diventa impotente quando si modificano i file inclusi. – Fr0sT
@ Fr0sT Non uso FMX, quindi non posso dire. Sotto XE1, i test semplici funzionano, ma si limitano a rilevare alcune delle modifiche all'unità dopo aver chiuso e riaperto il progetto. –
Non esiste una direttiva del compilatore perché tecnicamente non esiste un'applicazione Firemonkey o un'applicazione vcl. Solo le applicazioni che fanno uso di queste tecnologie. Un'applicazione può utilizzare fxm o vcl o entrambi o nessuno dei due (ad esempio un'app console). Questo è un po 'come chiedere se si tratta di un'applicazione SQL. Ovviamente è possibile controllare in modo programmatico l'ascendenza dei singoli moduli per vedere quale framework ereditano. Ancora, all'interno di un'unità che non ha una forma associata, questo non ha significato.
No, dovresti definire il tuo. – jed
Perché è necessario? Qualcosa puzza un po 'di pesce per me. –
si potrebbe desiderare di usare un'unità con funzionalità comuni in entrambe le applicazioni vcl e fmx, niente di strano. come: usa {$ IFDEF FMX} FMX.Forms {$ ELSE} Vcl.Forms; {$ ENDIF} –