Anzeigen wenn sich in TObjectList ein Eintrag geändert hat

[norwegen60]

Hallo zusammen,

ich möchte in einer TObjectList erkennen, wenn sich ein Object in der Liste geändert hat. Dazu habe ich folgendes (vereinfachtes) Konstrukt angedacht:

Delphi-Quellcode:

  // ***************************************************************************************************************************************
  // Die Basisliste mit dem Property Changed
  TBaseObjectList<T: class> = class(TObjectList<T>)
  private
    FChanged: Boolean;
  public
    constructor Create(AOwnsObjects: Boolean = True); overload;
    property Changed: TClass read FChanged write FChanged;
  end;

  // ***************************************************************************************************************************************
  // Die Basisklasse mit den zwei fixen Propteries
  TBase = class
  private
    FChanged: Boolean;
    FParentObject: TObject;
    procedure SetNr(Value: Integer);
    procedure SetChanged(const Value: Boolean);
  public
    property Changed: Boolean read FChanged write SetChanged;
    property ParentObject: TObject read FParentObject write FParentObject;

    constructor Create;
    destructor Destroy; override;
  end;

  // ***************************************************************************************************************************************
  // Als Beispiel eine auf ein eigenes Property abgespeckte Klasse
  TNamen = class(TBase)
  private
    FNamen: String;
    procedure SetNamen(const Value: String);
  public
    property Namen: String read FNamen write SetNamen;

    constructor Create;
    destructor Destroy; override;
  end;

  // ***************************************************************************************************************************************
  // Und die zu diesem Beispiel passende ObjectList
  TNamenList = TBaseObjectList<TNamen>;

Bei der Beschriftung der Eigenschaft Namen wird automatisch das Chanded-Property gesetzt

Delphi-Quellcode:

procedure TNamen.SetNamen(const Value: String);
begin
  if FNamen <> Value then
  begin
    FNamen := Value;
    Changed := True;
  end;
end;

Und jetzt soll über die Änderung des Changed-Property auch das Changed-Flag der entsprechenden Liste gesetzt werden. (Falls die Klasse einer Liste angehört), Dazu wurde dem Object bei der Erstellung die Liste als ParentObject mit gegeben

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if (FParentObject is TBaseObjectList) then        // Prüfen, ob der Parent des Wertes eine TBaseObjectList ist       Das geht so aber leider nicht
      TBaseObjectList(FParentObject).Changed := true; // Und wenn ja, die Liste auch auf Changed setzen
  end;
end;

Das Einlesen der Daten in die Liste würde so aussehen

Delphi-Quellcode:

procedure TForm15.btCreateListClick(Sender: TObject);
var
  i:Integer;
  lNamen:TNamen;
begin
  lNamenList := TNamenList.Create;
  for i:=0 to 5 do
  begin
    lNamen.Create;
    lNamenList.Add(lNamen);
    lNamen.ParentObject := lNamenList;
    lNamen.Namen := Format('Name%d', [i]);
    lNamen.Changed := False;
  end;
  lNamenList.Changed:=False;
end;

Jetzt stehen alle Werte und die Liste auf Changed = False

Und wenn ich so den Werte eines Eintrags ändere, steht dieser Wert auf Changed und es sollte auch die Liste auf Changed = True stehen

Delphi-Quellcode:

procedure TForm15.btChangeNameClick(Sender: TObject);
begin
  lNamenList[3].Namen := 'Neuer Name';   // Jetzt ist  lNamenList[3].Changed = True  und jetzt soll auch lNamenList.Changed = True sein
end;

Aktuell gehe ich bei jedem Save-Vorgang durch die verschiedenen Listen, aber es wäre eben resourcenschonender wenn ich gleich an der Liste selber sehen würde, ob ein Wert geändert wurde.

Gibte es eine Möglichkeit das zu realisiseren

Vielen Dank
Gerd

[dummzeuch]

Zitat:

Zitat von norwegen60 (Beitrag 1486488)

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if (FParentObject is TBaseObjectList) then        // Prüfen, ob der Parent des Wertes eine TBaseObjectList ist
      TBaseObjectList(FParentObject).Changed := true; // Und wenn ja, die Liste auch auf Changed setzen
  end;
end;

Ist das korrekt? Müsste es nicht heißen:

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if Value and <FParentObject is TBaseObjectList) then // <<< Änderung hier
      TBaseObjectList(FParentObject).Changed := true;
  end;
end;

Also nur wenn der neue Wert True ist, auch Changed der Liste auf True setzen?

Kann sein, dass es in Deinem Anwendungsfall keinen Unterschied macht, kommt mir aber falsch vor.

Zitat:

Zitat von norwegen60 (Beitrag 1486488)

Und wenn ich so den Werte eines Eintrags ändere, steht dieser Wert auf Changed und es sollte auch die Liste auf Changed = True stehen

So weit, so gut. Man kann anhand des Changed Flags der Liste erkennen, ob ein Eintrag in der Liste geändert wurde.

Mir ist nicht ganz klar, was Du damit meinst:

Zitat:

Zitat von norwegen60 (Beitrag 1486488)

Aktuell gehe ich bei jedem Save-Vorgang durch die verschiedenen Listen, aber es wäre eben resourcenschonender wenn ich gleich an der Liste selber sehen würde, ob ein Wert geändert wurde.

Gibte es eine Möglichkeit das zu realisiseren

Suchst Du nach einer Möglichkeit, neben der reinen Information, dass mindestens ein Eintrag in einer Liste geändert wurde, auch zu sehen, welche Einträge geändert wurden, ohne die Liste durchgehen zu müssen?

Das ginge z.B., indem man zusätzlich noch eine ChangedObjects Liste mit Pointern auf die geänderten Objekte pflegt. Dann braucht man beim Speichern nur die ChangedObjects Liste durchgehen, die Objekte speichern und ChangedObjects löschen.

Folgendes ist dabei zu beachten:

• Beim Löschen eines Eintrag aus der Hauptliste muss dieser ggf. auch aus der ChangedObjects Liste gelöscht werden.
• Multithreading würde hier nochmal deutlich komplexer.

Es ginge noch mit etwas geringerem Speicherverbrauch ohne eine ChangedObjects Liste, indem man einen Changed Counter führt und dann beim Abspeichern der Liste die Einträge nur so lange durch geht, bis man genau diese Anzahl Änderungen gefunden und gespeichert hat. Das spart im Durchschnitt etwas Zeit. Wenn man Pech hat, wurde aber der letzet Eintrag geändert und man muss alle Einträge durchgehen, bis man den geänderten gefunden hat. Das kann man nochmal etwas optimieren, indem man den kleinste und den größten Index der geänderten Objekte pflegt, allerdings ist das ziemlich kompliziert, falls auch Einträge hinzugefügt und gelöscht werden, denn dann muessen jeweils auch diese beiden Indexe angepasst werden.

[norwegen60]

Zitat:

Zitat von dummzeuch (Beitrag 1486490)

Ist das korrekt? Müsste es nicht heißen:

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if Value and <FParentObject is TBaseObjectList) then // <<< Änderung hier
      TBaseObjectList(FParentObject).Changed := true;
  end;
end;

Ja, da hast du natürlich recht. Das Problem ist aber, dass Delphi die Typprüfung

Delphi-Quellcode:

if (FParentObject is TBaseObjectList) then

nicht akzeptiert. Genauso wenig wie die Zuweisung

Delphi-Quellcode:

TBaseObjectList(FParentObject).Changed := true

. Und da suche ich nach einer Möglichkeit, wie ich auf die BasisListe per TypeCast zugreifen kann.

Das mit dem Counter oder der zusätzlichen Liste sind Möglichkeiten, machen die Listenverwaltung aber nicht einfacher.
In meiner Anwendung gibt es 61 TObjectList und von der ein oder anderen noch mehrere Instanzen.

[Uwe Raabe]

Versuch's mal so:

Delphi-Quellcode:

    if (FParentObject is TBaseObjectList<TBase>) then
      TBaseObjectList<TBase>(FParentObject).Changed := true;

[Uwe Raabe]

Konsequenterweise sollte man die Liste auch so deklarieren:

Delphi-Quellcode:

TBaseObjectList<T: TBase>

[norwegen60]

Vielen Dank
Mit den Änderungen lässt sich das Testprojekt jetzt compilieren. Aber zwei Dinge treten noch auf

• Die Abfrage
  Delphi-Quellcode:

  (FParentObject is TBaseObjectList<TBase>)

  bringt kein TRUE zurück, obwohl ich
  Delphi-Quellcode:

  lNamen.ParentObject := lNamenList;

  zugewiesen habe
• Spätestens wenn ich das Programm beende, kommt ein EAccessViolation auf. Kann aber auch schon passieren, wenn ich aus dem Programm in die IDE wechsle.

Ich bin nicht sicher, ob ich den Zusatz richtig verstanden habe

Zitat:

Zitat von Uwe Raabe (Beitrag 1486493)

Konsequenterweise sollte man die Liste auch so deklarieren:

Delphi-Quellcode:

TBaseObjectList<T: TBase>

Ich habe es auf verschiedene Arten probiert, das Verhalten blieb aber immer gleich

Delphi-Quellcode:

  TBaseObjectList<T: class> = class(TObjectList<T>)
  TBaseObjectList<T: TBase> = class(TObjectList<T>)
  TBaseObjectList<TBase: class> = class(TObjectList<TBase>)

[himitsu]

Problem ist, dass bei den Generics die Vererbung bissl "komisch" arbeitet und die Hierarchie nicht immer so aussieht, wie man denken könnte. :wall:


Aber ich hätte auch gedacht, dass es bei diesen 3 Varianten hätte gehen sollen, da du eigentlich auf den gleichen selben Typ prüfst und der ja gleich sein müsste. :gruebel:
Wobei 1 und 3 das Selbe ist, von den Typen her, da sich nur der Bezeichner unterscheidet. (ob es A oder B heißt, macht keinen Unterschied)
[EDIT] Das TBase in

Delphi-Quellcode:

is ...<TXyz>

war doch das TXyz aus

Delphi-Quellcode:

TBaseObjectList<TXyz: class> = ...

und nicht das "einzelne"

Delphi-Quellcode:

TBase = class

?

Aber bei

Delphi-Quellcode:

TBaseObjectList<T: TBase> = class(...

ist diese Prüfung auch nicht nötig, da bereits der Compiler die Prüfung übernimmt und du somit einfach "blind" hart casten kannst, weil es nichts Anderes sein kann.

[Uwe Raabe]

So sollte es auf der sicheren Seite sein:

Delphi-Quellcode:

type
  TBase = class;
  TBaseObjectList = class(TObjectList<TBase>)
  private
    FChanged: Boolean;
  public
    constructor Create(AOwnsObjects: Boolean = True); overload;
    property Changed: Boolean read FChanged write FChanged;
  end;
  TBaseObjectList<T: TBase> = class(TBaseObjectList);

Dann kannst du auch wieder auf TBaseObjectList prüfen und casten:

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
begin
  if FChanged <> Value then begin
    FChanged := Value;
    if (FParentObject is TBaseObjectList) then
      TBaseObjectList(FParentObject).Changed := True;
  end;
end;

[norwegen60]

Ich bin nicht sicher ob jetzt ein Teil meiner Anforderung verloren gegangen ist.

So wie TBase die Basisklasse für meine kommenden Objekte ist, sollte TBaseObjectList die Basisklasse für meine kommenden Listen sein

Eine der kommenden Klasse incl. Liste könnte dann so aussehen

Delphi-Quellcode:

  // ***************************************************************************************************************************************
  // Als Beispiel eine auf ein eigenes Property abgespeckte Klasse
  TNamen = class(TBase)
  private
    FNamen: String;
    procedure SetNamen(const Value: String);
  public
    property Namen: String read FNamen write SetNamen;

    constructor Create;
    destructor Destroy; override;
  end;

  // ***************************************************************************************************************************************
  // Und die zu diesem Beispiel passen ObjectList
  TNamenList<T: TNamen> = class(TBaseObjectList);

var
  lNamenList: TNamenList;

Wenn ich es so definiere

Delphi-Quellcode:

TNamenList<T: TNamen> = class(TBaseObjectList)

sagt Delphi bei Zugriff auf

Delphi-Quellcode:

lNamenList[3].Namen

dass er Namen nicht kennt

Wenn ich es so definiere

Delphi-Quellcode:

TNamenList = TBaseObjectList<TNamen>;

sagt Delphi bei Zugriff auf

Delphi-Quellcode:

lNamen :=  lNamenList[3];

dass TNamen und TBase incompatibel sind.

Wenn ich per Typecast

Delphi-Quellcode:

lNamen :=  TNamen(lNamenList[3]);

auf die Liste zugreife funktioniert die Änderung von lNamen.Namen und die Liste wird korrekt auf Changed gesetzt. Eigentlich wollte ich aber ohne TypeCast auskommen, zumal es viele Zugriffe gibt die direkt auf

Delphi-Quellcode:

lNamenList[3].Namen

zugreifen. Und beim Beenden des Programms kommt weiterhin der EAccessViolation.


Das hier verstehe ich nicht ganz

Delphi-Quellcode:

  TBaseObjectList = class(TObjectList<TBase>)
  private
  ...
  end;
  TBaseObjectList<T: TBase> = class(TBaseObjectList);

Soll es wirklich zwei mal TBaseObjectList heißen?

Ich habe mal mein Testcode angehängt. Hängt vielleicht nur noch an einer Kleinigkeit

[Uwe Raabe]

Ja, stimmt. Der generische Part der TObjectList<T> geht damit verloren. Wenn du das nicht nachbilden und trotzdem bei dem Ansatz mit dem ParentObject bleiben willst, kannst du entweder den HardCast auf TObjectList<TBase> vom Anfang machen oder über über ein OnChanged-Event oder ein Interface arbeiten.

Eine ganz andere Alternative wäre auch ein Message-Mechanismus:

Delphi-Quellcode:

const
  cNotifyChanged = 1;

type
  TBase = class;
  TBaseObjectList<T: TBase> = class(TObjectList<T>)
  private
    FChanged: Boolean;
  protected
    procedure NotifyChanged(var Message: TDispatchMessage); message cNotifyChanged;
  public
    property Changed: Boolean read FChanged write FChanged;
  end;

...

procedure TBase.SetChanged(const Value: Boolean);
var
  msg: TDispatchMessage;
begin
  if FChanged <> Value then begin
    FChanged := Value;
    msg.MsgID := cNotifyChanged;
    FParentObject.Dispatch(msg);
  end;
end;

...

procedure TBaseObjectList<T>.NotifyChanged(var Message: TDispatchMessage);
begin
  Changed := True;
end;

[norwegen60]

Gestern war ich ja mal richtig optimistisch, dass ich da bald zu einer Lösung kommme, aber der Optimismus schwindet.
Vielleicht liegt es ja an Delphi XE
Das Positive: Mit dem neuen Konstrukt funktioniert es zunächst mal einwandfrei

• Zugriff auf lNamen[i].Namen ist möglich
• FChanged der Liste wird gesetzt sobald ich lNamen[i].Namen ändere

Dann aber die Fehler
1. Sobald ich das Programm Schließe, kommt weiterhin der EAccessViolation. Ohne TBaseObjectList<T>.Destructor gleich beim lNamenListFree, mit Destructor nach dem OnClose
2. Das Abfangen, ob lNamen Mitglied einer Liste, funktioniert nicht. Auch wenn ich FParentProject explizit auf NIL setze, geht er in den Message-Block

Delphi-Quellcode:

constructor TBase.Create;
begin
  FParentObject := nil;
end;

procedure TBase.SetChanged(const Value: Boolean);
var
  msg: TDispatchMessage;
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if Value and (FParentObject <> nil) then // Geht in den Block auch wenn FParentObject = NIL
    begin
      msg.MsgID := cNotifyChanged;
      FParentObject.Dispatch(msg);
    end;
  end;
end;

3. Ganz seltsam wird es dann in folgenden Blöcken

Delphi-Quellcode:

procedure TForm15.btCreateListClick(Sender: TObject);
// *****************************************************************************************************************************************
// Simuliert Erstellung neuer Einträge
var
  i: Integer;
  lNamen: TNamen;
begin
  if (lNamenList = nil) then
    lNamenList := TNamenList.Create;

  for i := 0 to 5 do
  begin
    lNamen.Create;
    lNamenList.Add(lNamen);
    lNamen.ParentObject := lNamenList;
    lNamen.Namen := Format('Name%d', [i]);
    lNamen.Changed := False;
  end;
  lNamenList.Changed := False;

  laChanged.Caption := Format('lNamenList Count = %d, Changed = %d', [lNamenList.Count, Integer(lNamenList.Changed)]);
end;

procedure TForm15.btNameOnlyClick(Sender: TObject);
// *****************************************************************************************************************************************
// Simuliert StandAlone-Klasse, d.h. nicht in einer Liste
var
  lNamen: TNamen;
begin
  lNamen.Create;
  try
    lNamen.Namen := 'NameOnly';
  finally
    lNamen.Free;
  end;
end;

procedure TForm15.btNewNameClick(Sender: TObject);
// *****************************************************************************************************************************************
// Simuliert Hinzufügen eines Namens
var
  lNamen: TNamen;
begin
  lNamen.Create;
  lNamenList.Add(lNamen);
  lNamen.ParentObject := lNamenList;
  lNamen.Namen := Format('Name%d', [lNamenList.Count + 1]);

  laChanged.Caption := Format('lNamenList Count = %d, Changed = %d', [lNamenList.Count, Integer(lNamenList.Changed)]);
end;

• btCreateListClick funktioniert einwandfrei auch bei mehrfachem Aufruf
• btNameOnlyClick und btNewNameClick führen zu einem EAccessViolation in TNamen.Create. Dabei ist btNewNameClick doch genau gleich wie btCreateListClick mit dem einzigen Unterschied dass einmal 1 und einmal 6 neue Daten erstellt und in Liste eingefügt werden

[Uwe Raabe]

Wie lange programmierst du nun schon in Delphi und dann kommt immer noch sowas dabei heraus :shock:

Delphi-Quellcode:

var
  lNamen: TNamen;
begin
  lNamen.Create;
  try
    lNamen.Namen := 'NameOnly';
  finally
    lNamen.Free;
  end;
end;

Es heißt

Delphi-Quellcode:

lNamen := TNamen.Create

!!!!

[norwegen60]

Oh Shit. Natürlich heißt es

Delphi-Quellcode:

lNamen:= TNamen.Create;

.
Ein kompletter Leichtsinnsfehler. Wunderlich, dass es in der For Schleife trotzdem funktioniert. Und danach per Copy&Paste weiterverbreitet.

Und schon funktioniert alles wie gewünscht.

Vielen Dank

[norwegen60]

Also zuerst noch mal vielen Dank. Damit kann ich die bestehende Klassenstruktur demnächst mal um einiges vereinfachen.

An einer Stelle hänge ich aber noch:
Wie kann ich erkennen dass das ParentObject meine TBaseObjectList ist? In meinem Konstrukt kann ParentObject die TBaseObjectList sein. Es könnte aber auch eine von TBase abgeleitete Klasse sein, eine unabhängige Klasse oder NIL

Kein Problem mit NIL und den "normalen" Klassen, aber die Typprüfung nach der Liste klappt nicht.

Folgendes läuft zwar, aber mir wäre es lieber, ich würde die Message wirklich nur an meine TBaseObjectList schicken

Delphi-Quellcode:

procedure TBase.SetChanged(const Value: Boolean);
var
  msg: TDispatchMessage;
begin
  if FChanged <> Value then
  begin
    FChanged := Value;
    if Value then
    begin
      if (FParentObject is TBase) then
        TBase(FParentObject).Changed := Value
      // else if (FParentObject is TObjectList<TBase>) then  // funktioniert nicht, d.h. geht auch bei TObjectList nicht in den Block
      else if (FParentObject <> nil) then
      begin
        msg.MsgID := cNotifyChanged;
        FParentObject.Dispatch(msg);
      end;
    end;
  end;
end;

Das mit dem Dispatch war übrigens ein super Hinweis dessen Verwendung ich bisher gar nicht kannte.

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1486524)

ich würde die Message wirklich nur an meine TBaseObjectList schicken

Die Idee hinter der Message ist ja gerade, dass der Sender nicht weiß, ob und wie diese Message vom Empfänger behandelt wird. Die Default-Implementierung in TObject macht einfach gar nichts. Solange also deine alternativen ParentObject-Instanzen keine Message mit der Message-ID cNotifyChanged implementieren kannst du den Aufruf ruhig auf alles loslassen.

Der Grund für diesen Ansatz war ja gerade der, dass es keine brauchbare Möglichkeit gibt, zu prüfen ob ParentObject ein generische TBaseObjectList<T> ist oder nicht. Das war doch das eigentliche Problem in dem Eingangspost.

[norwegen60]

Alles klar.

Mein Hauptproblem war zuerst mal überhaupt eine BaseObjectList zu erzeugen die die Standardproperties enthält.
Ich war mir nicht sicher, ob das Senden der Message an alle nicht noch irgenwelche Zusatzlasten erzeugt

In dem Fall ist mein Problem vollumfänglich gelöst. Für mich eine sehr lehrreiche Lektion.
Vielen Dank für deine Geduld. Du bist einfach Spitze.

[generic]

Ich schmeiße hier mal eine andere Möglichkeit in den Raum.

Wenn ich programmiere, dann versuche ich nach SOLID zu programmieren.
Daher versuche ich meine Geschäftsobjekte nicht für andere Dinge zu erweitern.

"single responsibility principle"

Die Änderungserkennung ist für mich ein andere Geschäftsvorgang, weil dieses wird ggf. auch nicht in überall benötigt.

Meine Änderungserkennung ist mit den RTTI und Attributen umgesetzt:
https://youtu.be/pvi7-c6tGMo

Die Attribute müsste man in deinem Fall nicht einmal benutzen.

Alternativ zu meiner Umsetzung, werfe ich auch das Pattern UnitOfWork in den Raum.
Den Setter zu nutzen, halte ich allerdings für eine gute Lösung.
Man könnte alternativ einfach über einen BUS und ein Ereignis, die Änderung "global" zur Verfügung stellen.
Ha! - Video Idee - ich wollte sowieso mal den Delphi-BUS zeigen.


Die "Liste", welche du haben möchtest, hab ich auch umgesetzt. Es hat mir einfach zu stark in den Fingern gejuckt.
Das Video muss ich allerdings noch schneiden. Der Teil hatte kein Platz mehr in dem ersten, weil ich versuche zwischen 10-15 Minuten zu bleiben.
Ich denke das Video lade ich bis nächsten Montag in den Kanal.