Anzeigen wenn sich in TObjectList ein Eintrag geändert hat

[himitsu]

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


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.
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 is ...<TXyz> war doch das TXyz aus TBaseObjectList<TXyz: class> = ... und nicht das "einzelne" TBase = class ?

Aber bei 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 TNamenList<T: TNamen> = class(TBaseObjectList) sagt Delphi bei Zugriff auf lNamenList[3].Namen dass er Namen nicht kennt

Wenn ich es so definiere TNamenList = TBaseObjectList<TNamen>; sagt Delphi bei Zugriff auf lNamen := lNamenList[3]; dass TNamen und TBase incompatibel sind.

Wenn ich per Typecast 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 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

Delphi-Quellcode:

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

Es heißt lNamen := TNamen.Create !!!!

[norwegen60]

Oh Shit. Natürlich heißt es 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