Compilerschalter für Framework

[himitsu]

'nabend,

es gibt nicht zufällig ein Define für das im Projekt verwendete Framework?
Via

Delphi-Quellcode:

{$IFDEF MSWINDOWS/ANDROID/MACOS/IOS}

kann man zwar auf die Zielplattform prüfen, aber ob eine Windowsanwendung FMX oder VCL benutzt, kann ich in einer Unit irendwie nicht rausbekommen.

Grund: eine nichtvisuelle Komponente, welche man auf eine VCL oder FMX-Form legen kann.
Grundsätzlich geht das, aber was macht man, wenn man in der Komponente einen TTimer verwenden will?

Vcl.ExtCtrls oder Fmx.Types

Erst dachte ich, kein Problem, ich binde einfach ExtCtrls und Types ein und lass' über die definierten Namespaces entscheiden, da es beide Units beiden Frameworks gibt
und dann ist es mir egal, aus welcher Unit der Timer nun kommt.
FMX: Vcl.ExtCtrls, System.Types
VCL: Fmx.ExtCtrls, Fmx.Types

Leider klappt das bei ExtCtrls, aber nicht bei Types, denn System.Types, Vcl.Types und Fmx.Types


Die einzige Lösung, welche ich bis jetzt fand, ist die Kompoente doppelt zu entwicklen, aber das ist doch auch keine Lösung. :wall:

Delphi-Quellcode:

//Fmx.MyClass.pas
GroupDescendentsWith(TMyClass, Vcl.Controls.TControl);

//Vcl.MyClass.pas
GroupDescendentsWith(TMyClass, Fmx.Types.TControl);

Genauso wie den Timer selbst zu basteln auch nicht in Frage kommt. Oder in der VCL dennoch versuchen direkt auf IFMXTimerService zu gehn. :gruebel:

[Uwe Raabe]

Delphi-Quellcode:

unit VCL.Hybrids;

interface

uses
  Vcl.ExtCtrls;

type
  TTimer = Vcl.ExtCtrls.TTimer;

implementation

end.

Delphi-Quellcode:

unit FMX.Hybrids;

interface

uses
  FMX.Types;

type
  TTimer = FMX.Types.TTimer;

implementation

end.

Delphi-Quellcode:

unit Unit7;

interface

uses
  Hybrids;

type
  TMyTimer = class(TTimer)

  end;

implementation

end.

[himitsu]

Hmmm, auf die Idee nur den Timer abzuleiten, bin ich noch nicht gekommen.
Hätte beinah meine Klasse abgeleitet (mit 'ner virtuellen ErstelleTimer-Methode) und gehofft der Formdesigner kommt damit klar, daß es zwei Komponenten mit dem selben Namen gibt.

Komponentenentwicklung für MultiPlattform und MultiCompilerVersion gestaltet sich garnicht so einfach. :cry:

http://delphibistro.com/?p=206
http://stackoverflow.com/questions/1...th-vcl-and-fmx

[himitsu]

Irgendwas ist hier komisch (XE7, aber da hat sich bestimmt in XE8 eh nix verändert)

Firemonkeyanwendungen referenzieren die Winapi und Win, aber kein FMX? :shock:
Und ein nichtvisueller Service die VCL.

Das sind jeweils die Standardwerte von neuen Anwendungen.
erste+zweite Zeile = Namespaces der Ableitungen (vorallem Windows und MacOS ... Android ist in Ableitungen nicht überschrieben)
zweite Zeile = der Teil aus der Basiskonfiguration


FMX Metropolis
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap

Geräteübergreifend - 3D
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap

Geräteübergreifend - Leer
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap

Konsole
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap

Package
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap

Service
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell

VCL
Winapi;System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;
System;Xml;Data;Datasnap;Web;Soap;Vcl;Vcl.Imaging;Vcl.Touch;Vcl.Samples;Vcl.Shell

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1300870)

Firemonkeyanwendungen referenzieren die Winapi und Win, aber kein FMX?

Vermutlich geht man davon aus, daß FMX-Anwendungen immer voll qualifizierte Unitnamen verwenden. Aber: ja, das ist zumindest diskutabel. Für mein Beispiel oben musste ich FMX auch noch in die Liste aufnehmen.

Zitat:

Zitat von himitsu (Beitrag 1300870)

Und ein nichtvisueller Service die VCL.

Da Services eh nur unter Windows gehen, ist das zumindest nicht tragisch. Es würde somit auch keinen Sinn machen, hier mit Gewalt auf VCL verzichten zu wollen.

Zitat:

Zitat von himitsu (Beitrag 1300870)

erste+zweite Zeile = Namespaces der Ableitungen (vorallem Windows und MacOS ... Android ist in Ableitungen nicht überschrieben)

Hier unter XE8 sind nur die Windows-Konfigurationen entsprechend überschrieben.

[himitsu]

Da Services aber (standardmäßig) nichts visuelles Benutzen dürfen, wäre VCL im Standard dennoch falsch nicht ganz richtig.
Und da "Plattformübergreifend" vorallem für iOS (den Liebling von Emba) ist, wäre Winapi/Win dort total falsch. :stupid:

Soo, Feig.FrameworkCheck in die Uses und VCL.Feig.FrameworkCheck.pas, sowie FMX.Feig.FrameworkCheck.pas erstellt.
Leider heißt es dann dennoch "Datei Feig.FrameworkCheck.dcu nicht gefunden", obwohl VCL definiert ist.

Mit FeigFrameworkCheck, VCL.FeigFrameworkCheck.pas, FMX.FeigFrameworkCheck.pas und VCL oder FMX in den Optionen geht es aber.
Ebenso FrameworkCheck, VCL.Feig.FrameworkCheck.pas, FMX.Feig.FrameworkCheck.pas und VCL.Feig oder FMX.Feig (wobei hier Feig.VCL und Feig.FMX namentlich schöner wäre)
oder statt Namespaces ohne zusätzliche Units und dafür lieber mit einem DEFINE in den Projektoptionen.

Komisch ist nur, daß es mit System.Generics.Default.pas zu funktionieren scheint
und bei eigenen Units will der mehrstufige Namespace dann doch nicht. (ich glaub der Compiler hasst mich)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1300879)

Da Services aber (standardmäßig) nichts visuelles Benutzen dürfen, wäre VCL im Standard dennoch falsch nicht ganz richtig.

Die uses-Anweisung eines frisch erstellten Services sieht aber so aus:

Delphi-Quellcode:

uses
  Vcl.SvcMgr,

Dabei verweist Vcl.SvcMgr wiederum auf Vcl.Forms & Co.

Zitat:

Zitat von himitsu (Beitrag 1300879)

Und da "Plattformübergreifend" vorallem für iOS (den Liebling von Emba) ist, wäre Winapi/Win dort total falsch.

Ich weiß nicht, wie du das hinkriegst, aber eine geräteübergreifende Anwendung definiert bei mir in XE7 nur in den beiden Windows-Plattformen eine Ableitung zur Basiskonfiguration. OSX, iOS und Android übernehmen nur diese. Da steht nichts von Win.

[himitsu]

Ich hab mal das Projektsverzeichnis vom Delphi leer gemacht.
Jetzt ist wirklich nur noch Win32 und Win64 in den Basisconfigs überschrieben.

Es gab zwar .dproj.local , .identcache und .res mit dem selben Projektnamen, welchen Delphi für die neuen Projekte genommen hat, und daraus sollten eigentlich keine Projektoptionen kommen. :gruebel:

[Rollo62]

Hallo Himitzu,

ich bastele an einer VCL/FMX übergreifenden Bibliothek, und das funktioniert erstaunlich gut bei den Basics.
Natürlich muss man mal ein bischen Frameworkabhängigen Code schreiben, aber das lohnt sich.
So ist z.B. ein

Code:

BitmapLoadFromFile

bei
mir in VCL/FMX nutzbar, was für mich die Arbeit sehr vereinfacht.

Da habe ich das Gleiche Problem mit der Fameworkerkennung, und ich schreibe einfach ins globale Project/Defines mein USE_VCL oder USE_FMX rein.

Natürlich wird es dann schwierig wenn man Komponenten benutzen möchte, deshalb ist das nur eine Basisbibliothek.


Rollo

[himitsu]

Das mit den DEFINEs wollte ich wenn möglich lassen, da diese Fremdkomponente ja auch für Andere sein soll.

Vorallem da diese DEFINE einen kleinen Nachteil haben.
Der Compiler kompiliert die Dateien nicht von alleine neu, wenn man nur die DEFINEs ändert, da er an den Dateien ja keine Änderung erkennt. (man muß explizit ein Build ausführen)

Es gibt hier auch zwei Grundlegende Probleme beim Form-Designer.

1. Die Komponente tut nur zur Laufzeit intern entsprechenden Code nutzen. (in meinem Fall halt der TTimer und es ist direkt ein TComponentnachfahre)
2. Die Komponente wird schon im Designer jeweils unterschiedlich benötigt. (z.B. das Problem mit TColor und TAlphaColor oder bei visuellen Komponenten)

Bei ersterem kann man die selbe Komponente verwenden
und bei Zweitem muß man die Komponente bereits ableiten, da sie auch schon im Formdesigner zwei Versionen nötig sind.
Ich bin aber scon fast so weit, die Komponente doppelt zu entwickeln (TMyComponent und TMyComponentFmx), da sie eh nur sehr klein ist, aber ihre zukünftige Schwesterkomponente wird wesentlich aufwändiger.

Mein Package hab ich nun auch zum DesignOnlyPackage deklariert ... anders geht das garnicht, da die DCUs dort natürlich nur in einer Version kompiliert enthalten sein können.

Die Ausgabepfade sind auch mit entsprechenden Parametern versehn, damit die Compiler nicht durchdrehen.
Leider kann man das Framework dort nicht als Umgebungsvariable reinbekommen, aber Platform, Config und CompilerVersion sind schonmal ein Anfang.

Code:

Project Options (DesignPackage):
  DCU-Output       .\_Dcu\$(Platform)_$(Config)_$(ProductVersion)
  DCP-Output       .\_Bpl\$(Platform)_$(ProductVersion)
  BPL-Output       .\_Bpl\$(Platform)_$(ProductVersion)

Project Options (EXE):
  DCU-Output       .\_Dcu\$(Platform)_$(Config)_$(ProductVersion)
  EXE-Output       .\_Bin\$(Platform)_$(Config)
  PostBuildEvent   COPY /Y $(PROJECTDIR)\Lib\$(Platform)\*.* .\_Bin\$(Platform)_$(Config)\

PostBuildEvent, da natürlich auch noch die entsprechenden DLL/SO/LIB der Zielpattform mit ins Programmverzeichnis müssen.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1300919)

Leider kann man das Framework dort nicht als Umgebungsvariable reinbekommen,

Das Framework wird ja nur für den Designer benötigt und kann sich ja auch gelegentlich mal ändern (siehe MonkeyMixer). Es ist somit durchaus erlaubt, wenn auch nicht empfohlen, VCL und FMX in einem Projekt gleichzeitig zu verwenden. Insofern gibt es für den Compiler so etwas wie ein eindeutiges Framework gar nicht. Ein solcher Mix würde aber eine Unit, wie deine, die sich wahlweise auf VCL oder FMX bezieht, dann doch ausschließen.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1300920)

Ein solcher Mix würde aber eine Unit, wie deine, die sich wahlweise auf VCL oder FMX bezieht, dann doch ausschließen.

Außer es gibt wirklich zwei Komponenten.

Der Hauptgrund für die Entscheidung ist ja, daß ich bei Verwendung des FMX nicht die Units der VCL über meine Uses-Abschnitte ins Programm bringen will.
Wenn eh Beides im Programm benutzt wird, dann ist es im Endeffekt ja egal, was meine Komponente intern benutzt. :angle2:

Wenn man vor/im Uses global abfragen könnte, was für Units bereits (bis zu dieser Stelle) im Programm einkompiliert wurden und dann entsprechend die eigenen Uses anpasst.
Aber das geht leider auch nicht, denn wenn die eigenen Units vor den "entscheidenen" des Zielprogramms geladen/kompiliert werden....
Also Ideal wäre es gewesen, wenn man die Plattform-Option der Projektoptionen als DEFINE oder Variable vorgefunden hätte, sozusagen eine VCL-/FMXVersion ala CompilerVersion oder RTLVersion. :cry:

[Uwe Raabe]

Du könntest vielleicht zwei solche Units wie die beiden Hybrid-Units aus meinem Beispiel nehmen und dort jeweils eine Konstante FrameWorkVCL bzw. FrameWorkFMX deklarieren. Dann kannst du beim Compilieren über {$IF Declared(FrameWorkXXX)} abfragen, was gerade eingebunden wurde.

Delphi-Quellcode:

unit VCL.Hybrids;

interface

const
  FrameWorkVCL = 1;

implementation

end.

Delphi-Quellcode:

unit FMX.Hybrids;

interface

const
  FrameWorkFMX = 2;

implementation

end.

Delphi-Quellcode:

uses
  Hybrids,
{$IF Declared(FrameWorkVCL)}
  Vcl.ExtCtrls;
{$ELSE}
{$IF Declared(FrameWorkFMX)}
  FMX.Types;
{$IFEND}
{$IFEND}


{$IF Declared(FrameWorkVCL)}
const
  FrameWork = FrameWorkVCL;
{$ELSE}
{$IF Declared(FrameWorkFMX)}
const
  FrameWork = FrameWorkFMX;
{$IFEND}
{$IFEND}

type
  TMyTimer = class(TTimer)

  end;

[himitsu]

Delphi-Quellcode:

unit VCL.FeigFrameworkCheck;

interface

const
  FeigFramework = 'VCL';

implementation

end.

Delphi-Quellcode:

unit FMX.FeigFrameworkCheck;

interface

const
  FeigFramework = 'FMX';

implementation

end.

Delphi-Quellcode:

uses
  // Namespace/Unitscope: System, VCL/FMX, [Winapi]
  FeigFrameworkCheck,
  {$IF Defined(MSWINDOWS) and (FeigFramework = 'VCL')}
    {$IF CompilerVersion >= 24}
      Winapi.Windows,
    {$ELSE}
      Windows,
    {$IFEND}
  {$IFEND}
  SysUtils, Math;

Delphi-Quellcode:

uses
  // Namespace/Unitscope: System, Vcl/Fmx, [Winapi], [Feig]
  // Vcl.ExtCtrls and Fmx.Types for TTimer
  {$IF Defined(MSWINDOWS) and (FeigFramework = 'VCL')}
    {$IF CompilerVersion >= 24}
      Winapi.Windows,
    {$ELSE}
      Windows,
    {$IFEND}
    Vcl.ExtCtrls,
  {$ELSE}
    Fmx.Types,
  {$IFEND}
  Math, SysUtils, Classes, Feig.Types, Feig.USB, Feig.ISC;

Sieht bei mir so aus, wobei ich grade überlegt das eher auf FeigFrameworkIsVCL und FeigFrameworkIsFMX (Boolean) umzustellen.
Die erste Überlegung war mal ... Wer weiß was nach FMX kommt. :stupid: (FMX4, FMX5, CLX und die vielen .NET-Formsdinger)

Aber sicherheitshalber kommt noch ein

Delphi-Quellcode:

{$IFNDEF MSWINDOWS}

in die VCL-Datei kommt, falls jemand VCL auch in iOS/Android/Linux/MacOS definiert hat. :stupid: