Controls über Klassenname erstellen?

[sensei2]

Hallo,
ist es in Delphi möglich Steuerelemente zur Laufzeit über ihren Klassennamen zu erstellen?
Beispielsweise gebe ich in ein Edit "TButton" ein und es wird ein Button erzeugt.
Dies soll mit jedem beliebigen Klassennamen eines Steuerelementes funktionieren.

[martin_]

Ein Mini Beispiel:

Delphi-Quellcode:

  if edit.Text ='tbutton' then
  begin
    (TButton.Create(self)).parent := self;
  end;

[sensei2]

Das meine ich nicht. Es geht mir darum, dass man das mit jedem beliebigen Steuerelement machen kann. z.B auch mit TLabel, TEdit, TMemo... und ich möchte diese ungern alle per case abfragen und dann erstellen.
Ich bräuchte etwas wie

Delphi-Quellcode:

control:=TControl(getclass(edit1.text)).Create(self);
control.Parent:=self;

das funktioniert aber nicht.

[himitsu]

Dafür müßten die Klassen irgendwo in einer Liste registriert sein, was sie nicht sind.

Im Falle von GetClass müßtes du die Klasse vorher bei Classes.RegGroups registrieren.

[sensei2]

Kann man sich alle Componenten von Delphi auflisten lassen und diese dann registrieren?

[sx2008]

So sollte es gehen:

Delphi-Quellcode:

control:=TControlClass(FindClass(edit1.text)).Create(self);
// hier zuerst Left,Top, Height und Width setzen (bzw. SetBounds() aufrufen), bevor Parent gesetzt wird
// das verhindert unnötige Methodenaufrufe
control.Top := ...
control.Parent:=self;

Die harte Typumwandlung mit TConrolClass ist etwas gefährlich - hier könnte man besser mit "as" arbeiten
(aber ich kann's grad nicht ausprobieren)

Delphi-Quellcode:

control:=(FindClass(edit1.text) as TControlClass).Create(self);
control.Parent:=self;

[Tryer]

FindClass ist "GetClass() <> nil", bringt also eher noch weniger. (TControlClass(False))?

Eine passende Liste gibt es zur Laufzeit einfach nicht.
Selber erstellen, oder bleiben lassen.

MfG,
Dirk

[Bernhard Geyer]

Ich denke im Rahmen der RTTI müsste sich u.U noch einiges verstecken. Denn Delphi-Apps müssen ihre Formulare auch aus der Exe streamen und die IDE erkennt ja auch wenn DFM-Klassenangaben nicht mit den der Pas-Datei übereinstimmen.

[Apollonius]

Das ist richtig. Klassen, die mit M+ kompiliert wurden, speichern für jedes als published deklarierte Feld den Namen und den Typen. Aus dem Typen lässt sich mittels ClassName leicht der Name erhalten.

Das Problem ist bei Verwendung dieser Informationen allerdings, dass sich auf diese Weise eben nicht der Typ TEdit erhalten lässt, wenn kein Edit auf dem Formular liegt, was aber anscheinend im Sinn des Threaderstellers liegt.

[sx2008]

Zitat:

Zitat von Tryer

FindClass ist "GetClass() <> nil", bringt also eher noch weniger.

FindClass wirft eine Exception, wenn die Klasse nicht gefunden wird.
Das ist ist hier ein erwünschtes Verhalten.

Zitat:

Zitat von Tryer

Eine passende Liste gibt es zur Laufzeit einfach nicht.

Dann frage ich mich, wie ein Formular seine Komponenten erzeugt ohne dass explizit Aufrufe ala Label1 := TLabel.Create(self) vorhanden sind.
Die Informationen sind da; blos die VCL verbirgt sie vor dem Programmierer.

[Tryer]

Entschuldigung, da hab mich vertan. Findclass gibt ja auch die Klasse zurück. Das eine Exception gewollt ist sehe ich nicht.

Was alles nichts an dem Problem ändert:

Ohne zur Enwurfszeit die Unit 'xy' einzubinden hat das Programm auch nicht die Chance "Txy" zu erstellen - nur weil "Delphi es kennt". Es stehen ja keine "globalen" Typinformationen zur Verfügung sondern nur die von Elementen welche ich im Entwurf schon in Verbindung mit meinem Programm gebracht habe.

Vielleicht gibt es eine Chance das Dateisystem nach dcu´s zu durchforsten und herauszufinden welche Klassen darin zur Verfügung gestellt werden. Diese müsste man dann zur Laufzeit einbinden.
Der Aufwand wird auf jeden Fall viieeel grösser als der mal eben ein paar _sinnvolle_ Klassen im Vorfeld einzubinden und deren Erzeugung anzubieten. Selbst dabei ist der Aufwand nicht ohne, schliesslich muss ich dem Anwender ja auch noch die Möglichkeit geben die Objekte zu benutzen, also auf Caption/Text/Lines/... zuzugreifen.
Das ganze läuft auf eine "eigene IDE" hinaus.

Worum genau geht es bei dem Projekt eigentlich ?

MfG,
Dirk

[Reinhard Kern]

Zitat:

Zitat von Tryer

Vielleicht gibt es eine Chance das Dateisystem nach dcu´s zu durchforsten und herauszufinden welche Klassen darin zur Verfügung gestellt werden. Diese müsste man dann zur Laufzeit einbinden.

Hallo,

so oder so, in jedem Fall würde der Programmumfang maximiert - praktisch müsste die Exe (oder DLLs) alles enthalten was überhaupt in Delphi definiert ist plus vom Programmierer eingebundene Fremdkomponenten. Die EXE würde wohl zig MByte gross, schliesslich müsste sie in etwa den Umfang des Delphi-Entwicklungssystems haben abzüglich Editor und Debugger.

Die Problemstellung ist ähnlich wie bei einem eingebauten Delphi-Interpreter.

Gruss Reinhard

[SirThornberry]

Mir stellt sich bei dem ganzen folgende Frage:
Wozu das ganze? Was bringt einem eine erstellte Komponente mit Default-Eigenschaften der keine Ereignisse zugewiesen wurden etc.? Was bringt dir zum Beispiel ein Button dem kein Klick-Ereignis zugewiesen ist. Oder eine Listview ohne Inhalt und ohne Möglichkeit den ViewStyle umzustellen etc.?
Es wäre interessant zu wissen was insgesamt bezweckt werden soll um eine optimale Lösung dafür zu finden.

Zitat:

Vielleicht gibt es eine Chance das Dateisystem nach dcu´s zu durchforsten und herauszufinden welche Klassen darin zur Verfügung gestellt werden. Diese müsste man dann zur Laufzeit einbinden.

Dann müsstest du einen Compiler/Linker schreiben/integrieren. Denn deine Exe ist bereits ein Produkt aus compilieren und linken. Eine dcu hingegen ist nur etwas vorkompiliertes was man nicht zur Laufzeit einfach einbinden kann. (die dcu's der verschiedenen Delphiversionen unterscheiden sich auch und verweigern ihren Dienst wenn sie mit verschiedenen Versionen anderer dcu's zusammen kompiliert wurden)
Vergleichbar mit einem Auto. Da hilft es dir auch nicht einen Metallklumpen mitzuführen um jederzeit ein Ersatzteil daraus formen zu können. Da werden auch Maschienen benötigt den Klumpen Metall zu irgendwelchen Teilen zu verarbeiten.

Du müsstest also schon zur Entwurfszeit wissen was alles in deine Programm soll und entsprechend alle units mit einbinden. Und da kannst du auch gleich eine eigene Liste erstellen mit allen Klassen die man erstellen können soll.
Aber wie bereits im ersten Abschnitt von mir geschrieben wäre es interessant zu wissen was mit dem ganzen bezweckt werden soll um zu schauen ob das überhaupt ins Gesamtkonzept passt.