Mit Datenmodul arbeiten

[Walter Landwehr]

Hallo, ich glaube das mit dem Datenmodul habe ich noch nicht richtig gecheckt.

Also ich habe ein Formular nennen wir es frmMitglieder ( die Unit heißt: Mitglieder ) Dazu habe ich einen Datenmodul dmMitglieder (Unitname: Datamod_Mitglieder).

auf dem Formular frmMitglieder habe ich ein Label lblAlter. Nun möchte ich beim OnChange Ereignis die Farbe des Labels wechseln. Leider bekomme ich eine Zugriffsverletzung weil mein frmMitglieder Nil ist. Weis jemand was ich machen muss damit es funktioniert.

Hier mal der Code aus dem Datamodul:

Delphi-Quellcode:

unit Datamod_Mitglieder;

interface

uses
  System.SysUtils, System.Classes, Data.DB, IBODataset, Vcl.Graphics;

type
  TdmMitglieder = class(TDataModule)
    LookupQry: TIBOQuery;
    LookupSrc: TDataSource;
    MitgliederQry: TIBOQuery;
    dscMitglieder: TDataSource;
    AnredeQry: TIBOQuery;
    dscAnrede: TDataSource;
    dscTitel: TDataSource;
    dscBerufe: TDataSource;
    BerufeQry: TIBOQuery;
    TitelQry: TIBOQuery;
    PLZQry: TIBOQuery;
    procedure dscMitgliederDataChange(Sender: TObject; Field: TField);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  dmMitglieder: TdmMitglieder;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

uses Mitglieder, ToolsOperation;

{$R *.dfm}

procedure TdmMitglieder.dscMitgliederDataChange(Sender: TObject; Field: TField);
begin
   if MitgliederQry.FieldByName('GEBURTSDATUM').AsString <> '' then
    frmMitglieder.lblAlter.Caption := 'Alter: ' + IntToStr(ToolsOperation.CalcYearsInPeriod(MitgliederQry.FieldByName('GEBURTSDATUM').AsDateTime, Date));
  if CalcBirthday(dmMitglieder.MitgliederQry.FieldByName('GEBURTSDATUM').AsDateTime) then
    frmMitglieder.lblAlter.Font.Color := clRed
  else
    frmMitglieder.lblAlter.Font.Color := clBlack;
  if (MitgliederQry.FieldByName('GEBURTSDATUM').AsString <> '') then
    frmMitglieder.lblAlter.Visible := True
  else
    frmMitglieder.lblAlter.Visible := False;
end;

end.

Das Datenmodul wird im OnCreate des Formulars frmMitglieder erzeugt.

Delphi-Quellcode:

procedure TfrmMitglieder.FormCreate(Sender: TObject);
begin
  dmMitglieder := TdmMitglieder.Create(frmMitglieder);
  ToolsForm.RestoreWindowPosition(Self);
end;

Wer weiß Abhilfe.

[Sherlock]

Dein Datenmodul soll Daten bereitstellen, und soll/darf/muss alle anderen Units des Projekts gar nicht kennen. Änderungsereignisse werden demzufolge klassischerweise in der Form-Unit abgehandelt.

Sherlock

[Walter Landwehr]

Wie soll man denn auf ein OnChange Ereignis reagieren? Das Formular bekommt dies ja nicht mit.

[Bentissimo]

Ich vermute hier liegt ein kleines Missverständnis vor. Ein OnChange-Event wird typischerweise von GUI-Controls erzeugt, hier geht es aber wohl eher um ein OnDataChange-Event einer DataSource.

In diesem Fall würde ich eine Message an das Formular schicken, eventuell sogar als Broadcast. Günstiger wäre aber wohl die Verlagerung der DataSource auf das Formular.

[Walter Landwehr]

Ja das ist richtig mit dem OnChange des DataSet. Ich hatte das bisher so, das alles auf der Form lag, aber mit der Zeit ist das Formular völlig überfrachtet. Darum die Idee mit dem Datamodul. War wohl nicht so eine gute Idee oder? Wie kann ich denn eine Message an die Form schicken und darauf reagieren.

[Lemmy]

oder du sorgst dafür, dass im Form das OnDataChange-Ereignis nach dem Erstellen mit dem DataSet auf dem DM verbunden wird. Bisher sah ich keinen Grund das nicht so zu machen.

[mjustin]

Zitat:

Zitat von Walter Landwehr (Beitrag 1336695)

Ja das ist richtig mit dem OnChange des DataSet. Ich hatte das bisher so, das alles auf der Form lag

Es spricht - solange keine Master/Detail DataSources in den DataSets benötigt werden - nichts dagegen, die DataSource weiterhin auf dem Formular zu lassen. Sie vermittelt zwischen GUI Controls und Datenbank-Komponenten. Messages zu versenden würde bedeuten das "RAD" noch einmal zu erfinden. Und es ensteht so auch keine ("zirkuläre") Abhängigkeit des Datenmoduls vom Formular.

[bcvs]

Oder Du spendierst dem Datamodul ein selbst definiertes Ereignis als Property, nennen wir es OnMitgliederDataChange.

Delphi-Quellcode:

procedure TfrmMitglieder.FormCreate(Sender: TObject);
begin
  dmMitglieder := TdmMitglieder.Create(frmMitglieder);
  dmMitglieder.OnMitgliederDataChange:=MitgliederDataChange; 
emd;

procedure TfrmMitglieder.MitgliederDataChange;
begin
  lblAlter.Caption := 'Alter: ' // ... und was sonst noch zu tun ist;
end;

procedure TdmMitglieder.dscMitgliederDataChange(Sender: TObject; Field: TField);
begin
  if assigned(OnMitgliederDataChange) then
    OnMitgliederDataChange;
 //  ...
end;

Vorteil: Das Datamodul muss dein frmMitglieder nicht kennen. So wie du es momentan hast, gibt es da ja eine zirkuläre Unit-Referenz, auch wenn die durch das Uses Mitglieder im Implementation-Teil nicht zu Tage tritt.

[mjustin]

Zitat:

Zitat von bcvs (Beitrag 1336700)

Oder Du spendierst dem Datamodul ein selbst definiertes Ereignis als Property, nennen wir es OnMitgliederDataChange.

Auch eine Lösung, allerdings mit einer Einschränkung (gegenüber dem Platzieren der DataSource auf dem Formular): mehrere nicht-modale Formulare können nicht auf das selbe DataSet zugreifen und dieses Event zuweisen. (Es würde immer nur das zuletzt zuweisende Formular 'gewinnen').

[Sherlock]

Wir reden hier doch von klassischen datengebundenen Komponenten (zB TDBEdit, denen eine TDataSource zugewiesen werden kann, oder? Durch diese Zuweisung sind sämtliche Kommunikationskanäle eingerichtet, die man benötigt. Ich weiß nicht was da schief gehen könnte. Ich habe die letzten 15 Jahre solche Projekte vor mir gehabt. Livebindings freilich ändern alles, und ich kann nichts erhellendes beitragen.

Sherlock

[p80286]

*gelöscht*
Gruß
K-H

[mm1256]

Hallo Walter,

die Trennung macht durchaus Sinn. Wenn man es aber macht, dann bitte konsequent so wie schon mehrfach vorgeschlagen, und nicht irgend so einen Misch-Masch wo sich dann wieder Teile des Datenzugriffes auf den Formularen befinden.

Mein Vorschlag: Diese procedure gehört in das Formular

Delphi-Quellcode:

procedure TfrmMitglieder.dscMitgliederDataChange(Sender: TObject; Field: TField);
begin
  ...
end;

Beim "OnActivate" und "OnDeactivate" würde ich sie jeweils im Formular zuweisen

Delphi-Quellcode:

procedure TfrmMitglieder.FormActivate(Sender: TObject);
begin
  dmMitglieder.dscMitglieder.OnDataChange := dscMitgliederDataChange;
end;
procedure TfrmMitglieder.FormDeActivate(Sender: TObject);
begin
  dmMitglieder.dscMitglieder.OnDataChange := nil;
end;

Abgesehen davon würde ich die Datenmodule generell in der .dpr erzeugen, denn oft ist es ja so, dass bei konsequenter Anwendung der Datenmodule (absolute Trennung von Datenzugriff und GUI) dann mehrere Formulare das Datenmodul problemlos verwenden können. Unterm Strich wird zudem sogar der Bildschirmaufbau etwas schneller weil die Tabelle offen bleiben kann und das Datenmodul nicht ständig neu erzeugt werden muss.

[Der schöne Günther]

Zitat:

Zitat von mjustin (Beitrag 1336697)

Es spricht - solange keine Master/Detail DataSources in den DataSets benötigt werden - nichts dagegen, die DataSource weiterhin auf dem Formular zu lassen. Sie vermittelt zwischen GUI Controls und Datenbank-Komponenten. Messages zu versenden würde bedeuten das "RAD" noch einmal zu erfinden. Und es ensteht so auch keine ("zirkuläre") Abhängigkeit des Datenmoduls vom Formular.

Genau so mache ich das auch immer :-)

Der DataSource (auf dem Formular) hat ein OnDataChange-Event (auf dem Formular) das etwas ... auf dem Formular auslöst. Schön einfach und trotzdem sauber getrennt. 8-)

[bcvs]

Zitat:

Zitat von mm1256 (Beitrag 1336707)

Mein Vorschlag: Diese procedure gehört in das Formular

Delphi-Quellcode:

procedure TfrmMitglieder.dscMitgliederDataChange(Sender: TObject; Field: TField);
begin
  ...
end;

Das wird in diesem Fall nicht viel weiter helfen, da der TE im dscMitgliederDataChange des DataModuls auch auf andere Komponenten im Datamodul zugreift. Deshalb mein Vorschlag mit dem Event. Dadurch werden die Aktionen des DM von denen des Formulars getrennt.

[Walter Landwehr]

Hallo Otto,

Klappt, Danke

[mm1256]

Zitat:

Zitat von bcvs (Beitrag 1336716)

...mein Vorschlag mit dem Event. Dadurch werden die Aktionen des DM von denen des Formulars getrennt.

Stimmt, das ist ein gutes Argument. :thumb: Man ist damit flexibler, falls doch einmal etwas im Datenmodul zu erledigen wäre (was Walter aktuell zwar nicht braucht, aber das kommt bestimmt noch

@Walter Verbesserungsvorschlag:

Delphi-Quellcode:

program Project1;

uses
  Vcl.Forms,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas' {DataModule1: TDataModule};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  // Datenmodule vor dem Hauptformular erzeugen
  Application.CreateForm(TDataModule1, DataModule1);
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

//**************************************************************************************

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB;

type
  TForm1 = class(TForm)
    procedure FormActivate(Sender: TObject);
    procedure FormDeactivate(Sender: TObject);
  private
    { Private-Deklarationen }
    procedure FormularUpdate(DataSet: TDataSet);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

uses Unit2;

procedure TForm1.FormActivate(Sender: TObject);
begin
  DataModule1.FormularUpdateEvent := FormularUpdate;
end;

procedure TForm1.FormDeactivate(Sender: TObject);
begin
  DataModule1.FormularUpdateEvent := nil;
end;

procedure TForm1.FormularUpdate(DataSet: TDataSet);
begin
  // Hier das Formular updaten
end;

end.

//**************************************************************************************

unit Unit2;

interface

uses
  System.SysUtils, System.Classes, FireDAC.Stan.Intf, FireDAC.Stan.Option,
  FireDAC.Stan.Param, FireDAC.Stan.Error, FireDAC.DatS, FireDAC.Phys.Intf,
  FireDAC.DApt.Intf, FireDAC.Stan.Async, FireDAC.DApt, Data.DB,
  FireDAC.Comp.DataSet, FireDAC.Comp.Client;

type
  TFormularUpdateEvent = procedure(DataSet: TDataSet) of object;
  TDataModule1 = class(TDataModule)
    FDQuery1: TFDQuery;
    procedure FDQuery1AfterScroll(DataSet: TDataSet);
    procedure DataModuleCreate(Sender: TObject);
  private
    { Private-Deklarationen }
    FFormularUpdateEvent: TFormularUpdateEvent;
  public
    { Public-Deklarationen }
    property FormularUpdateEvent: TFormularUpdateEvent
             read FFormularUpdateEvent write FFormularUpdateEvent;
  end;

var
  DataModule1: TDataModule1;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.dfm}

procedure TDataModule1.DataModuleCreate(Sender: TObject);
begin
  FormularUpdateEvent := nil;
end;

procedure TDataModule1.FDQuery1AfterScroll(DataSet: TDataSet);
begin
  // Erledige hier alles, das mit dem direkten Zugriff auf
  // Komponenten im Datenmodul zusammen hängt
  // ...
  // Formular aktualisieren:
  if Assigned(FormularUpdateEvent)
  then FormularUpdateEvent(DataSet);
end;

end.

Was mich bei dieser Gelegenheit zu der Frage veranlasst, wie man es denn eigentlich "richtig" macht?

Delphi-Quellcode:

So:
  if Assigned(FormularUpdateEvent)
  then FormularUpdateEvent(DataSet);

oder so:

  if Assigned(FFormularUpdateEvent)
  then FFormularUpdateEvent(DataSet);

[Sir Rufo]

Zitat:

Zitat von mm1256 (Beitrag 1336734)

Was mich bei dieser Gelegenheit zu der Frage veranlasst, wie man es denn eigentlich "richtig" macht?

Delphi-Quellcode:

So:
  if Assigned(FormularUpdateEvent)
  then FormularUpdateEvent(DataSet);

oder so:

  if Assigned(FFormularUpdateEvent)
  then FFormularUpdateEvent(DataSet);

Das ist Geschmackssache und kommt daruf an, was du genau möchtest.

Willst du das Ergebnis vom Getter oder den Wert der Variablen? Damit entscheidet sich, was du verwenden musst ;)

[mm1256]

Na ja, in diesem Fall ist es was die Funktionalität anbelangt prinzipiell egal. Ich persönlich nehme innerhalb des Objekts lieber die "F"-Variante, wenn die Property direkt auf die Objektvariable zeigt. Mit Getter und Setter würde ich dann lieber auf die Property zugreifen.

[Rollo62]

Die Frage wäre was wäre schneller: Getter per "read FFieldVariable" oder Fieldvariable ?

Ich gehe mal einfach davon aus das der Compiler das inline setzt und gleich schnell sein wird.
Aber ist das wirklich so ?

Zumindest wenn der Getter per "read GetFieldVariable" mit

Delphi-Quellcode:

Result := FFieldVariable;

gemacht wird vermute ich mal der reine Variablenzugriff ist schneller.

Rollo