AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Datenmodule, die nicht von TDataModule kommen

Ein Thema von CalganX · begonnen am 25. Jun 2005 · letzter Beitrag vom 26. Jun 2005
Antwort Antwort
Seite 1 von 3  1 23      
CalganX

Registriert seit: 21. Jul 2002
Ort: Bonn
5.403 Beiträge
 
Turbo Delphi für Win32
 
#1

Datenmodule, die nicht von TDataModule kommen

  Alt 25. Jun 2005, 22:56
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
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#2

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 25. Jun 2005, 23:01
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?
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
Benutzerbild von Sharky
Sharky

Registriert seit: 29. Mai 2002
Ort: Frankfurt
8.252 Beiträge
 
Delphi 2006 Professional
 
#3

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 25. Jun 2005, 23:01
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".
Stephan B.
"Lasst den Gänsen ihre Füßchen"
  Mit Zitat antworten Zitat
CalganX

Registriert seit: 21. Jul 2002
Ort: Bonn
5.403 Beiträge
 
Turbo Delphi für Win32
 
#4

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 10:55
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
  Mit Zitat antworten Zitat
Robert_G
(Gast)

n/a Beiträge
 
#5

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 11:56
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...

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.
  Mit Zitat antworten Zitat
CalganX

Registriert seit: 21. Jul 2002
Ort: Bonn
5.403 Beiträge
 
Turbo Delphi für Win32
 
#6

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 12:12
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
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#7

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 12:17
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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
Robert_G
(Gast)

n/a Beiträge
 
#8

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 12:41
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 )
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.
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#9

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 13:22
Typische DP-Experten Diskussion. 8)

Mir stellen sich aber hierzu 2 Fragen :

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 ?

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 ?
Gruß
Hansa
  Mit Zitat antworten Zitat
Robert_G
(Gast)

n/a Beiträge
 
#10

Re: Datenmodule, die nicht von TDataModule kommen

  Alt 26. Jun 2005, 13:33
@Hansa
Warum mischst du dich immer in Dinge ein von denen du anscheinend keinen Schimmer hast?
Zitat von Hansa:
Sofern mit "repo" das Repository gemeint ist, also die Objektablage, was hat das mit einem Package zu tun ?
Oh ja, du würdest sogar eine Komponente installieren können, die in einer Echse steht. Nicht wahr großer Meister?
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...
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:57 Uhr.
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