Unterschiedliche DFMs für ein Formula r/ Varianten?

[sonicus83]

Hallo,

für ein Projekt passe ich gerade eine firmeninterne Software für ein Partnerunternehmen an. Es sind im allgemeinen nur ein paar Details, die ich bisher über Compilerschalter gelöst habe. Nun steht aber an, dass die Oberfläche geändert werden soll (Schriftgröße, daraus folgend aber das gesamte Layout).

Gibt es eine Möglichkeit (ggf. per Compilerschalter), verschiedene DFMs einzubinden und zwischen diesen "umzuschalten"? Oder müsste ich das ganze per Hand lösen (jeweils umbenennen per Batch fällt mir jetzt ein..).

Danke für jeden hilfreichen Hinweis.

[BerndS]

Hallo, wäre es nicht einfacher das Original abzuleiten und dann das jeweils benötigte entweder per Bedingung oder über einen Compilerschalter zu erzeugen.

[hoika]

Hallo,
mir fallen da Frames ein.

[freimatz]

Mir fällt da ein separater branch im VCS ein.

[himitsu]

Oder ein dynamisches Layout, welches sich an die Größe der Komponenten anpasst. (selbstständig Nachbarkomponenten verschiebt)

z.B. TGridPanel und seine neuen Freunde

[himitsu]

Delphi-Quellcode:

implementation

{$R *.dfm}

Das bindet die DFM-Ressource ein und man kann natürlich auch eigene Ressourcen einbinden.
(per Code oder über den RessourcenManager des Pojektes = DPROJ)

Geladen wird die Ressource dort: (Vcl.Forms.pas bzw. damals Forms.pas)
TCustomForm.Create > InitInheritedComponent > InternalReadComponentRes

Aber nein, die Funktionen, welche den Namen der Ressource bestimmen (heißt so, wie die Form) sind nicht "einfach" via Override zu ändern, damit du dort dann einen anderen Namen nehmen könntest.



Andere Lösung: Vererbung

Delphi-Quellcode:

type 
  TDeineAbleitung = class(TDeineGrundForm)
    ...
  end;

In dem Nachfahren kann man Komponenten verschieben, ausblenden/einblenden (Visible) und alle anderen Property ändern, wie z.B. Font/Top/Left/Height/...
Man kann auch neue Komponenten hinzufügen. (nur löschen lassen sich im Nachfahren keine geerbten Komponenten)

[Uwe Raabe]

Das Problem ist weniger das Einbinden einer anderen DFM als Resource als das Editieren dieser im Form-Designer.

Insofern würde ich auch den Vererbungs-Ansatz empfehlen. Am besten noch (wenn nicht schon vorhanden) mit zwei separaten Projekt-Dateien, in denen dann nur die benötigen Ableitungen eingebunden sind.

[himitsu]

Für den Formdesigner müssen die Forms/Versionen sowieso in getrennten eigenen Units liegen, da er pro Unit nur einen Designer hat.

[Rollo62]

Als Anregung: Firemonkey verwaltet ja verschiedene Forms, vermutlich so wie Du das brauchst:
http://docwiki.embarcadero.com/RADSt...Device_Project

Das sieht dann so aus

Delphi-Quellcode:

{$R *.fmx}
{$R *.Windows.fmx MSWINDOWS}
{$R *.iPhone4in.fmx IOS}
{$R *.LgXhdpiPh.fmx ANDROID}

Könnte man evtl. in VCL mit IFDEFS nachbilden, oder womöglich geht das bereits ähnlich in VCL ?

[Uwe Raabe]

Allerdings hat der FMX-Designer auch die Möglichkeit diese Ansichten zu bearbeiten. Das kann der VCL-Designer nicht.