Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Datenmodule, die nicht von TDataModule kommen (https://www.delphipraxis.net/48470-datenmodule-die-nicht-von-tdatamodule-kommen.html)

mirage228 26. Jun 2005 12:36

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 12:41

Re: Datenmodule, die nicht von TDataModule kommen
 
@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 26. Jun 2005 14:14

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 17:15

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 18:14

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 18:31

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 18:47

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 19:05

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 19:19

Re: Datenmodule, die nicht von TDataModule kommen
 
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 26. Jun 2005 20:08

Re: Datenmodule, die nicht von TDataModule kommen
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:06 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz