Form + DataModule mehrere Instanzen

[Nersgatt]

Zitat:

Zitat von smallie (Beitrag 1377804)

Sollte es nicht reichen, die Datensourcen auf das Formular zu setzen, dann können die Formulare unabhängig voneinander in den Daten scrollen. Das Datenmodul darf Singleton bleiben.

In der Regel lade ich die Daten durch ein TuniQuery in ein TClientDataset. Der Query übergebe ich Parameter an den SELECT, damit die Datenbank für mich nur die relevanten Daten raus filtert.
Wenn ich nun 2 Instanzen mit verschiedenen Parametern öffnen möchte, benötige ich diese 2 Instanzen des Datenmoduls. Sonst müsste ich noch das ClientDataSet auf das Formular packen. Das möchte ich nicht, das finde ich unübersichtlich.

[himitsu]

Wir haben einen TDataSource-Nachfahren der ein DataSet (pgDAC) drin hat.
Im Create holt der sich auch selber standardmäßig erstmal die Connection von einem globalen DataModul. (kann man notfalls danach was Anderes zuweisen ... man könnte sich da auch die erste Connection auf dem gemeinsamen Owner suchen, wenn im BeforeOpen noch keine Connection zugewiesen)

Dann noch paar Dinge, wie z.B. das SQL-Property, durchgereicht und als Published in die DataSource.


Nur eine Komponente auf der Form. (inkl. Preload der Default-Werte im AfterInsert uvm.)


Ist wie TLabeledEdit ... man kann TEdit und TLabel alleine auf die Form packen, oder zusammen.
Zusammen kann/sollte man aber TLabeledEdit nochmal ableiten und die Label-Caption etwas schöner in dem Edit platzieren.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1377803)

Im FormDesigner wird aber auch hier dennoch die globale Instanz verwendet.

Das ist ja auch so gewollt! In der IDE kann es ja auch nur eine Instanz des Forms geben (insbesondere wird dabei ja die lokale Instanz des Datenmoduls dort auch nicht erzeugt - nur zur Runtime) und das kann man ja bequem mit der Datenmodul-Instanz verknüpfen. Per Definition sind ja die Designtime-Instanz des Datenmoduls und die diversen Runtime-Instanzen vom selben Klassentyp.

Die Lösung ist vom Programmieraufwand her recht simpel und eingängig. Man muss lediglich im TForm.Create eine lokale Datenmodul-Instanz erzeugen und entsprechend benennen bevor man inherited aufruft.

Eigentlich kann das Datenmodul-Property im Form auch ganz anders heißen, solange der Name der Instanz passt. Will man diese Instanz nicht auch noch im Code selbst ansprechen, muss man die nicht mal als Property oder Feld deklarieren. Eine einzige Zeile reicht dann schon:

Delphi-Quellcode:

constructor TForm198.Create(AOwner: TComponent);
begin
  TMyDataModule.Create(Self).Name := 'MyDataModule';
  inherited;
end;

[himitsu]

Delphi-Quellcode:

{FFormVariableMyDataModuleOderSo :=} TMyDataModule.Create(Self, 'MyDataModule');

Wenn FFormVariableMyDataModuleOderSo ein Published-Feld mit dem Namen 'MyDataModule' ist, dann kümmert sich die VCL um das Befüllen dieser Variable.
TComponent.Name setzt automatisch ein eventuell vorhandenes gleichnamiges Published-Feld im Owner. Und beim Free/Destroy setzt es das auch wieder auf nil.

Ich hätte hier nur wegen des Owners leichte Bedenken gehabt. Die Child-Liste existiert ja noch nicht, aber scheinbar wird sie hier angelegt.
Vor dem Inherited ist ja noch nichts initialisiert. (alle Felder stehen auf 0 bzw. NIL, da vor der Constructor-Methode, zumindestens schonmal der Speicher mit NewInstance besorgt wurde)