Generisches Formular

[hansmaad]

Hallo zusammen.
Ein generisches Formular

Delphi-Quellcode:

View<Type> = class(TForm)

mit dem Formulareditor erstellt. Geht das nicht? Hab gerade versucht in der dfm Datei rumzuhacken, das ist aber natürlich nicht gut gegangen.

Kann man diesem Editor außderdem nicht abgewöhnen, unbedingt eine globale Instanz anlegen zu wollen, die dann den Klassennamen bestimmt?

[himitsu]

Sobald ein Formular per Create erstellt wird und wenn dabei der Klassenname nicht TForm entspricht, wird versucht eine gleichnamige DFM zu laden.

Der generische Type hat hat aber einen eigenen (von Delphi zusammengebauten) Namen und genau so müßte die Resource in der DFM heißen, was sie wohl nicht macht, falls du sie überhaupt erstellt hast.

Ergo: Du mußt das Laden der DFM abändern, dafür einen eigenen Namen verwenden, welcher für alle diese Generics gleich ist und natürlich die Resource der DFM so benennen.

[hansmaad]

Das klingt mir zu kompliziert:wink:

Ich hab es jetzt mal so gemacht:
Mit dem Formulareditor ein Form

Code:

TView = class(TForm)

erstellt. Davon leite ich dann

Code:

MyView<Type> = class(TView)

ab.

[s.h.a.r.k]

Ich glaub, ich verstehe, was himitsu meint:

Delphi-Quellcode:

unit Unit1;

interface

uses {...};

type
  TForm1 = class(TForm)
    { ... }
  end;

implementation

{$R Unit1.dfm} // <- here you go... Normalerweise steht da {$R *.dfm}.

end.

Zudem kannst du ja auch ein TForm ohne DFM-Datei erzeugen, weshalb du dann die Komponenten selbst via Code justieren musst. Aber da gibts doch ein nettes Tool in GExperts soweit ich weiß. (DFM-to-Code oder sowas...)

[himitsu]

Delphi-Quellcode:

{$R Unit1.dfm} // <- here you go... Normalerweise steht da {$R *.dfm}.

nja fast.


"*" steht für den Namen der Unit, also dieses ist praktisch, wenn man z.B. eine DFM/RES fest an eine Unit binden will.
(vorallem falls man diese Unit und ihre DFM mal umbenennt)

In der DFM steckt aber eine Formular-"Resource", welche einen bestimmten Namen hat.
Nun muß dieser interne Name mit dem Klassennamen des Formulars übereinstimmen.

Denn die VCL versucht aus den Programmresourcen der EXE dieses zu laden, eben über den Namen, sobald es sich um einen TForm-Nachfahren handelt.
Fehlt diese Resource oder hat sie einen falschen/anderen Namen, dann knallt es in der VCL.
Der Name der DFM-Datei ist dabei vollkommen egal ... dieser wird nur vom VCL-Defigner der Delphi-IDE benötigt, damit man da dieses Formular schön leicht editieren kann. (den Compiler stört ein anderer Dateiname aber nicht)

[s.h.a.r.k]

Bei mir (Delphi XE) wurde gemeckert, als ich da

Delphi-Quellcode:

{$R Unit2.dfm}

geschrieben hatte? :gruebel:

[shmia]

Also ich kann den Sinn und Zweck eines "generischen Formulars" nicht erkennen.
Ein Formular ist keine Klasse, die man irgendwie mit einem Template verknüpfen könnte.
Bei TList<Type> sieht das anderst aus.
Eine Liste eines bestimmten Datentyps macht Sinn.
Aber ein Formular eines bestimmten Datentyps??

[himitsu]

Wenn man das Formular, bzw. die GUI zur Datenhaltung nimmt, dann wäre es schon "sinnvoll" :roll:

[shmia]

Einspruch!
Eine Liste vom Objekt TControl oder eine Liste von Integern - eine Liste hat ganz definierte Operationen: Einfügen, über einen Index zugreifen, Löschen, Anzahl ermitteln, Zwei Elemente vertauschen...
Nur weil man bei einer Liste ganz bestimmte (abstrakte )Operationen kennt, die unabhängig von Datentyp sind, ist es möglich davon ein Template zu erzeugen.
Das Template bringt dann "nur" noch die Typsicherheit; schliesslich könnte man das Alles auch mit TObjectList oder TList erreichen (ohne Typsicherheit).
Das Template braucht den Datentyp nicht zu kennen; es verwaltet ledigt Instanzen eines beliebigen Datentyps in einer Liste.

Aber was sind die definierten Operationen eines Formulars?
Vielleicht "Anzeigen" und "Ändern".
Wie aber soll ein einziges Formular als Template das bewerkstelligen ohne tieferes Wissen über den Datentyp?
Man kann nicht etwas anzeigen, was man nicht kennt.
Über RTTI kann man published Properties und Events anzeigen und sogar verändern.
Das wäre dann ein Runtime-Objektinspektor.

Aber welchen Sinn würde dann TInspectorForm<TSpielfeld> oder TInspectorForm<TGameHistory> machen?
In dem Fall wäre die Typsicherheit völlig nutzlos, denn man braucht doch nur ein normales TInspectorForm und kann dann beliebige Objekte übergeben, anzeigen und ändern.


PS: ich glaube der Knackpunkt ist:
Eine Template-Klasse muss an anderer Stelle benützt werden, damit die Typsicherheit einen Sinn ergibt.
Ein TList-Template kann sehr häufig von anderem Code verwendet werden.
Es ist Bestandteil der Bussineslogik.
Ein Formular bildet dagegegen den Endpunkt, das äusserste Blatt.
Es gibt keine Bussineslogik, die ein Formular benützt sondern im Gegenteil Formulare benützten Bussineslogik.
Daher braucht ein Formular keine Typsicherheit.