Datenmodule, die nicht von TDataModule kommen

[CalganX]

Hi,
ich hab ein kleines Problemchen, da Delphi nicht ganz kapiert, was ich will. Da ich ein wenig mit OOP rumspielen muss, habe ich eine Basis-TDataModule-Klasse, die ungefähr so aussieht:

Delphi-Quellcode:

type
  TBaseModule = class (TDataModule)
    {...}
  end;

Nun sieht das auch ganz schnuckelig aus. Es wird keine DFM-Datei eingebunden, weil ich der Meinung war, dass ich keine brauche, da sich keine Komponenten auf dem Modul befinden, sondern nur ein paar Felder und ein paar Methoden (teilweise abstrakt). Nun habe ich aber eine Nachfahren-Klasse, die ungefähr so aussieht:

Delphi-Quellcode:

type
  TChildModule = class (TBaseModule)
    {...]
  end;

Hier wird eine Resourcen-DFM-Datei eingebunden, weil sich hier auch einige non-visuelle Komponenten befinden (außerdem werden die abstrakten Methoden implementiert).

Soweit so gut. Das Problem ist, dass Delphi nicht kapiert, dass es sich bei TChildModule um ein Datenmodul handelt, sondern es wie ein Formular behandelt. Das ist schlecht, sehr schlecht sogar, weil in der DFM von TChildModule stehen Dinge drin, die gar nicht existieren, wie z.B. die Eigenschaft Color. Das ist deswegen schlecht, weil dem entsprechend auch die Meldung beim Starten des Programmes kommt:

Zitat:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt xpFileMoverDemo.exe ist eine Exception der Klasse EReadError mit der Meldung 'Eigenschaft Color existiert nicht.' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

Wie kann man Delphi dazu bringen, dass er die DFM einfach in Ruhe lassen soll, oder die Klasse TChildModule wie ein Datenmodul handhaben soll?

Chris

[alzaimar]

Wozu benötigst du denn eine Ableitung von TDatamodule, wenn Du die DFM nicht willst? Oder auch anders gefragt: Was stört dich an einer DFM?

[Sharky]

Hai Chakotay,

warum leitest Du denn TBaseModul überhaupt von TDataModule ab? Schreibe Dir doch einfach deine Klasse welche Du von TObject ableitest. Dann hast Du dafür garaniert auch kein "DFM mehr am Hals".

[CalganX]

Hi,
@alzaimar: Hm. Naja, so gesehen nichts, aber ich dachte jetzt erstmal, dass ich die nicht brauche, weil das Base-Datenmodul keine Komponenten beinhaltet. Warum brauche ich also DFM?

@Sharky: Naja, das Problem ist halt, dass mein Child-Datenmodul Komponenten beinhalten wird. Und warum dann ein zusätzliches Datenmodul erzeugen, wenn es auch direkt geht? So gesehen muss ich das so machen, da nachher noch auf diese Komponenten zugegriffen werden soll. Sicher kann ich das über Felder und dynamische Komponenten machen, aber das ist nicht ganz der Sinn der Anforderung. ;)

Chris

[Robert_G]

Das Problem bei sämtlichen visual designing Krams in D32 ist, dass du /immer/ über das Object repo ableiten /musst/.
Du erzeugst dir also ein Package.
Dein TBaseModule bekommst über das DataModule template. Nun erzeugst du dein TChildModule über FileßNew\Others suchst dir den Reiter, der so heißt wie dein Package, wählst TBaseModule aus und [OK].
Du kannst jetzt beide visuell designen.
Jetzt noch eine kleine Unit in der du das Registrieren in die IDE übernimmst:

Delphi-Quellcode:

interface

uses
   Classes;

procedure Register;

implementation
uses
   uBaseModule,uChildModule;
procedure Register;
begin
   RegisterComponents('DP Samples',[TBaseModule, TChildModule]);
end;

Auf die Art kannst du dir visuell eine Komponente erstellen auf der du andere Komponenten platzieren und bearbeiten kannst.

DataModule <> Datenbankprogrammierung. ;) Sehe es ähnlich als ob du in .Net auf new Component klickst.
Dummerweise sind alle Komponenten auf dem DataModule published.
Wobei das durch das komische Konzept von DFM-Resourcen anstatt generierten Code wie in .Net verursacht wird.
Willst du das verstecken, musst du noch einen Wrapper darum schreiben. :?

Ich hoffe ich habe verstanden, was du vorhattest... :gruebel:

btw:
Lösche diese DAU-Variablen aus den generierten Units raus. Die verhindern, dass man damit auch nur irgendwas brauchbares anstellen kann.

@alzi
Es ist a) größer die Einstellungen in eine DFM zu packen und b) ist es langsamer wenn die ganze Initialisierung erst die DFM auslesen muss. (Und das für /jeden/ Vorfahren!) Ich denke das störte ihn. ;)

[CalganX]

Hi Robert,
uff... okay, das bedeutet einiges an Arbeit.
Danke für die Tipps, aber ich bin jetzt erstmal eine Woche ein Spanien. Ich guck mir das Ganze an, wenn ich wieder hier bin (nächste Woche Samstag).

Chris :hi:

[alzaimar]

Ich verstehe nicht, wie man 21.Jahrhundert auf 3-6GHZ Büchsten noch einen Gedanken an einige Bytes DFM-Initialisierung verschwendet, aber gleichzeitig auf die VCL zurückgreift. Deshalb finde ich die Überlegungen bezüglich EXE (RC)-Größe und Initialisierungscodeausführungsverzögerungen ehrlich gesagt überflüssig wie einen Kropf. Das geht nicht gegen irgendjemanden, sondern allgemein: Man sollte seine eigenen Resourcen (Gehirnschmalz) nicht dafür verschwenden.

Meine Meinung.

Eigene Datenmodule benutze ich auchg: Dort sind meine Standarddatenbank- und Repositorykomponenten enthalten...

Man darf nie vergessen, das in der Delphi-Hilfe überall steht, das die VCL-Komponenten als Basis für eigene Komponeten dienen (können) und nicht der Weisheit letzter Schluss sind.

[Robert_G]

Zitat:

Deshalb finde ich die Überlegungen bezüglich EXE (RC)-Größe und Initialisierungscodeausführungsverzögerungen ehrlich gesagt überflüssig wie einen Kropf.

Auch wenn's gehörig OT ist. Schaue dir mal an, wie GetClass und Treader implementiert sind.
Für jedes *piep* Objekt wird die ganze *piep* Liste durchrannt wiss die nötige MetaClass gefunden wird. Natürlich werden dabei /jedesmal/ string-Vergleiche gemacht. Die VCL ist voll von Ecken und Kanten, die nie eine Optimierung erfahren haben.
Auch wenn es dir unnütz erscheinen mag, lange darüber nachzdenken. (Ich selbst opfere liebend gerne auch mal mehr als 5% Performance für hübscheren Code :zwinker: )
Ein Form auf dem ein paar frames liegen, die wiederum Frames enthalten können, welche alle von Basisframes ableiten braucht mehr als 1 Sekunde zum Laden. Nur zum Laden! Ohne alles andere. Die einzige Möglichkeit, die ich damals gesehen habe um zu verhindern, dass der User meine App für "sluggish" hält war, sämtlichen Mist in Code zu hämmern. -> geiles RAD-Konzept! :?

Zitat:

Ich verstehe nicht, wie man 21.Jahrhundert auf 3-6GHZ Büchsten noch einen Gedanken an einige Bytes DFM-Initialisierung verschwendet...

Lass mal, ich verstehe nicht, wie man im Jahre 2005 noch auf File\New\VCL Application klicken kann. ;)

[Hansa]

Typische DP-Experten Diskussion. 8)

Mir stellen sich aber hierzu 2 Fragen :

Zitat:

Zitat von Robert_G

Das Problem bei sämtlichen visual designing Krams in D32 ist, dass du /immer/ über das Object repo ableiten /musst/.
Du erzeugst dir also ein Package.

Sofern mit "repo" das Repository gemeint ist, also die Objektablage, was hat das mit einem Package zu tun ? :shock:

Zitat:

Zitat von Robert_G

ist es langsamer wenn die ganze Initialisierung erst die DFM auslesen muss. (Und das für /jeden/ Vorfahren!)

Inwiefern interessiert die DFM der Vorfahren ? So ein Effekt müßte sich bei mir massiv bemerkbar machen. Warum merke ich nichts davon ?

[Robert_G]

@Hansa
Warum mischst du dich immer in Dinge ein von denen du anscheinend keinen Schimmer hast? :gruebel:

Zitat:

Zitat von Hansa

Sofern mit "repo" das Repository gemeint ist, also die Objektablage, was hat das mit einem Package zu tun ? :shock:

Oh ja, du würdest sogar eine Komponente installieren können, die in einer Echse steht. Nicht wahr großer Meister? :lol:

Zitat:

Zitat von Hansa

Inwiefern interessiert die DFM der Vorfahren ? So ein Effekt müßte sich bei mir massiv bemerkbar machen. Warum merke ich nichts davon ?

Hättest du auch nur etwas mehr gelesen (dabei das Denken und Verstehen nicht vergessen!) wären dir auch noch Frames aufgefallen, die wiedrum Vorfahren haben.
Und nun rate mal woher die Werte des Vorgängers zum Nachfolger finden? Richtig! Es wird erst die DFM der Vorgänger ausgelesen und dann die der zu erstellenden Form/Frame-Klasse. Was ja eigentlich absolut llogisch sein sollte...

btw: Gewöhne dir einfach ab auf meine Posts zu antworten. Solange du mich nicht direkt fragst, ist es einfacher den Kauderwelsch zu ignorieren...

[mirage228]

Hey Leute, ich will ja hier nicht den Klugscheißer spielen, aber imho seid ihr (mal wieder) gehörig OT - die Defizite der VCL sind nicht Thema dieser Diskussion.
Es geht hier mehr um Chris' Frage, die, soweit ich das sehe, schon beantwortet wurde.

mfG
mirage228

[Daniel]

@Robert und @Hansa: Klärt das bitte per PN. Weitere Auseinandersetzugnen in diesem Thread werde ich nicht dulden und Beitrag entsprechend entfernen.
Im Übrigen gibt es nicht die geringste Notwendigkeit, sich auf die persönliche Ebene zu begeben.

[alzaimar]

Zurück zum Thema:
Formulare, also auch Datenmodule lassen sich hervorragend ableiten, nämlich unter Zuhilfenahme der Object Repositry (Objekt-Ablage). Dazu erstellt man das Datenmodul/Formular, rechter Mausklick->Objekt-Ablage oder wie das heisst, und fertig. Eine Instanz erzeugt man mit Datei->Neu->Andere.

Und was die Performance anbelangt: Windows-User sind ja schon einiges gewohnt, also isses interessant zu wissen, das die VCL suboptimal ist, aber eigentlich auch egal.

@Robert: GetClass ist wirklich endgeil implementiert :wall:

[Hansa]

Zitat:

Zitat von Daniel

..Im Übrigen gibt es nicht die geringste Notwendigkeit, sich auf die persönliche Ebene zu begeben.

So sehe ich das auch. Allerdings erwarte ich zu diesem Thema eine konkrete Beantwortung meiner Fragen. Insbesondere von Robert_G :mrgreen:

[Robert_G]

Ich will mich ja nicht über Auswirkungen deines Nicks lustig machen ( :zwinker: ) aber kiek mal:

Zitat:

Zitat von alzaimar

Zurück zum Thema:
Formulare, also auch Datenmodule lassen sich hervorragend ableiten, nämlich unter Zuhilfenahme der Object Repositry (Objekt-Ablage).

Icke

Das Problem bei sämtlichen visual designing Krams in D32 ist, dass du /immer/ über das Object repo ableiten /musst/.
Du erzeugst dir also ein Package.
Dein TBaseModule bekommst über das DataModule template. Nun erzeugst du dein TChildModule über FileßNew\Others suchst dir den Reiter, der so heißt wie dein Package, wählst TBaseModule aus und [OK].

OT-Ecke:

Zitat:

Zitat von alzaimar

@Robert: GetClass ist wirklich endgeil implementiert :wall:

Es ist hauptsächlich der Reader, der mir sauer aufstösst. ;)
Der könnte sich nämlich alle schon gefundenen MetaClasses merken und somit die Suchzeit reduzieren.
Ansonsten solltest du Borland mal dein StringDictionary schicken. Über einen numerischen Hash sucht/sortiert es sich doch gleich viel schöner. :)

[Hansa]

Robert, es geht nicht um Besserwisserei ! Ausweichen zählt auch nicht ! Deshalb nochmals : was hat ein package mit dem Repository zu tun ? Die zweite Frage war, wieso OOP-mäßige Sachen etwas mit den DFMs zu tun haben sollen ?

Du hast geschrieben, das wäre langsam usw. Da ich nun die Objektablage als einer der wenigen intensiv nutze und keinerlei Performance-Einbußen in dieser Richtung feststellen kann, ist die Frage schon interessant ! Für den Hauptspeicher-Bedarf gilt ähnliches. Darum gehts und nicht darum, ob irgendeiner Recht hat. 8)

[Robert_G]

Zitat:

Zitat von Hansa

Robert, es geht nicht um Besserwisserei !

Ging es noch nie. ;)

Zitat:

Zitat von Hansa

Deshalb nochmals : was hat ein package mit dem Repository zu tun ? Die zweite Frage war, wieso OOP-mäßige Sachen etwas mit den DFMs zu tun haben sollen ?

Wenn du meinen Beitrag sorgfältig gelesen hättest (dieser Teil ist nun schon 2-mal in dem Thread zu sehen!), wäre dir aufgefallen, dass ich damit Klassen meinte, die im visuellen Designer bearbeitet werden können.
So wie ich Chris' Frage verstanden hatte wollte er eine Möglichkeit haben, sich visuell eine Komponente zusammenklicken zu könnnen.
Das macht wenig Sinn, wenn man sie nicht auch auf ein Form ziehen kann, right? Und da man seine Klassen sowieso in Packages ablegen sollte (IMHO) und man nur über Packages Klassen in die IDE registrieren kann, sollte es offensichtlich sein, dass hier ein Package benötigt wird. ;)

Zitat:

Zitat von Hansa

Du hast geschrieben, das wäre langsam usw. Da ich nun die Objektablage als einer der wenigen intensiv nutze und keinerlei Performance-Einbußen in dieser Richtung feststellen kann, ist die Frage schon interessant !

Es wird merklich langsam, wenn man wirklich mehrere Vorgänger eines Forms hat und diese auch einige Frames verwenden, die wiederum einige Vorgänger haben.
So kann es schnell passieren, dass zig DFMs durchlaufen werden um auch nur ein Form darzustellen.

Zitat:

Zitat von Hansa

Für den Hauptspeicher-Bedarf gilt ähnliches. Darum gehts und nicht darum, ob irgendeiner Recht hat. 8)

Ich kann dir hier nicht ganz folgenden, aber da die DFMs an sich nicht wirklich groß sind bzw. auch wieder entladen werden sehe ich hier kein Problem für den RAM. ;)

[Hansa]

Zitat:

Zitat von Chakotay1308

Da ich ein wenig mit OOP rumspielen muss

Aber das ist kein Spielzeug, sondern ein Werkzeug !

Zitat:

Zitat von Chakotay1308

Hier wird eine Resourcen-DFM-Datei eingebunden, weil sich hier auch einige non-visuelle Komponenten befinden (außerdem werden die abstrakten Methoden implementiert).

Chris hat übrigens noch was von Color erzählt. In meinen Datenmodulen ist davon nichts zu sehen. Außerdem geht es mir hauptsächlich um die Aussage, daß die DFM der Vorfahren eine Rolle spielt. Das sehe ich anders. Über das Package reden wir erst gar nicht. 8)

[Robert_G]

Machst du das mit Absicht, weil du weißt, dass ich darauf allergisch reagiere oder hast du eine seltene Form von Leseschwäche, die alle relevanten Informationen aus einem Text ausblendet?
Beides würde erklären wie du das...

Zitat:

in der DFM von TChildModule stehen Dinge drin, die gar nicht existieren, wie z.B. die Eigenschaft Color.

...und das..

Zitat:

Hier wird eine Resourcen-DFM-Datei eingebunden, weil sich hier auch einige non-visuelle Komponenten befinden

...mal wieder komplett ignoriert hast und somit Fragen gestellt hast, die schon vor zig Posts beantwortet wurden. :roll:
Wenn du etwas Talent für Abstraktion und Assoziation beweist könnte es sogar dir möglich sein anhand des letzten Zitats und meines vorherigen Beitrages den Sinn von Packages in dem Fall zu deduzieren...

btw: Das war jetzt geheuchelt freundlich verfasst.
Frage mich bitte nie wieder etwas auf diese arrogante Art, ohne dass du vorher über das Gelesene nachgedacht hast.

[Daniel]

STOP!

Ich möchte auch nicht nur einen einzigen weiteren Beitrag, der nicht zum Thema gehört! Klärt das per PN. Dies ist nun schon die zweite Aufforderung und ich werde Euer Streitgespräch morgen weitgehend aus diesem Thread entfernen.

[Hansa]

Zitat:

Zitat von Daniel

...ich werde Euer Streitgespräch morgen weitgehend aus diesem Thread entfernen.[/b]

Und das völlig zu Recht ! Im Laufe der Diskussion haben sich 2 konkrete Fragen gestellt. Hierfür gibt es folgende Möglichkeiten :

1. klare detailierte Antwort
2. "ich weiß es nicht"
3. keine Antwort 8)

Alles andere nützt keinem was.