Ein Object in TObjectList<T> löschen mit Ereignis

[RWarnecke]

Im Beitrag 7, siehst Du im Anhang, wie der Setter von FOnDelete arbeitet. Ebenfalls im gleichen Beitrag hatte ich geschrieben, dass ein Assigned(FOnDelete) immer False ergibt.

Ich habe noch ein bisschen weiter getestet. Wenn ich die TCustomObjectList<T: class> für die Klasse TDegree folgendermaßen erstelle :

Delphi-Quellcode:

  DegreeList := TCustomObjectList<TDegree>.Create;
  DegreeList.OnDelete := TableEntryDelete;

Funktioneren beide Quelltexte aus den Beiträgen 1 und 7 und die Funktion für FOnDelete wird ausgeführt. Lasse ich diese Zeile

Delphi-Quellcode:

DegreeList.OnDelete := TableEntryDelete;

weg, dann wird FOnDelete nichtmehr ausgeführt oder es wird die Access Violation angezeigt, wenn die Abfrage auf Assigned(FOnDelete) fehlt. Deshalb gehe ich davon aus, das das FOnDelete im Notify auf das FOnDelete in der TCustomObjectList<T: class> zeigt.

Ich stelle mir jetzt nur die Frage, warum FOnChange so funktioniert und FOnDelete nicht ?

[stahli]

Hat sich Dein Compiler irgendwie verschluckt?
Hast Du einen Compilerpoint (möglicher Breakpoint) in der Zeile?
Hast Du mal Projekt bereinigen/bneu erzeugen versucht?

[RWarnecke]

Zitat:

Zitat von stahli (Beitrag 1189394)

Hat sich Dein Compiler irgendwie verschluckt?

Weiß ich nicht.

Zitat:

Zitat von stahli (Beitrag 1189394)

Hast Du einen Compilerpoint (möglicher Breakpoint) in der Zeile?

Wie meinst Du das ?

Zitat:

Zitat von stahli (Beitrag 1189394)

Hast Du mal Projekt bereinigen/bneu erzeugen versucht?

Ich habe bis jetzt immer vor jedem Compilieren die DCU-Dateien und die EXE gelöscht.

[stahli]

Ich meinte den kleinen blauen Punkt vor jeder Befehlszeile (auf den man zum Setzen eines Breakpoints klickt).
Gelegentlich fehlten die bei mir schon mal, wenn der Compiler mit meinen Units nicht zurecht kam. :stupid:

Es gibt noch die Projektoptionen Bereinigen, Erzeugen und ggf. Installieren (bei Packages).
Vielleicht hilft davon ja etwas.

[RWarnecke]

Zitat:

Zitat von stahli (Beitrag 1189400)

Ich meinte den kleinen blauen Punkt vor jeder Befehlszeile (auf den man zum Setzen eines Breakpoints klickt).
Gelegentlich fehlten die bei mir schon mal, wenn der Compiler mit meinen Units nicht zurecht kam. :stupid:

Ich habe die Klassen in einer ganz normalen Unit. Wenn ich STRG+F9 drücke, erscheinen in dieser Unit keine blauen Punkte. Ist das schlimm ?

Trotzdem steht ja immer noch meine Frage im Raum, warum FOnChange so funktioniert und FOnDelete nicht. Ist mein Sourcecode denn überhaupt richtig oder habe ich einen Fehler gemacht ?

[Sir Rufo]

Zitat:

Zitat von RWarnecke (Beitrag 1189388)

Im Beitrag 7, siehst Du im Anhang, wie der Setter von FOnDelete arbeitet. Ebenfalls im gleichen Beitrag hatte ich geschrieben, dass ein Assigned(FOnDelete) immer False ergibt.

Ich habe noch ein bisschen weiter getestet. Wenn ich die TCustomObjectList<T: class> für die Klasse TDegree folgendermaßen erstelle :

Delphi-Quellcode:

  DegreeList := TCustomObjectList<TDegree>.Create;
  DegreeList.OnDelete := TableEntryDelete;

Funktioneren beide Quelltexte aus den Beiträgen 1 und 7 und die Funktion für FOnDelete wird ausgeführt. Lasse ich diese Zeile

Delphi-Quellcode:

DegreeList.OnDelete := TableEntryDelete;

weg, dann wird FOnDelete nichtmehr ausgeführt oder es wird die Access Violation angezeigt, wenn die Abfrage auf Assigned(FOnDelete) fehlt. Deshalb gehe ich davon aus, das das FOnDelete im Notify auf das FOnDelete in der TCustomObjectList<T: class> zeigt.

Ich stelle mir jetzt nur die Frage, warum FOnChange so funktioniert und FOnDelete nicht ?

Wenn du irgendwo hingreifst (weil da was sein soll), da aber nichts ist, dann kommt eine AV. Das sollte jedem klar sein.

Dein Code aus Beitrag 1

Delphi-Quellcode:

procedure TCustomObjectList<T>.Notify(const Item: T;
  Action: TCollectionNotification);
begin
  if                        // Wenn
    Assigned( FOnChange )   // dem Event was zugewiesen ist 
  and                       // und
    ( FNewRecord )          // FNewRecord wahr ist 
  and                       // und
    ( Action <> cnRemoved ) // die Aktion <> Entfernt ist
  then                      // dann
    begin
      FNewRecord := False;
      FOnChange(Self);
    end;

  if                    // Wenn
    Action = cnRemoved  // die Aktion = Entfernt ist
  then                  // dann
    begin
      FOnDelete(Item);  // knallt es hier, wenn FOnDelete = nil ist !!!!!
    end;

  inherited Notify(Item, Action); // hier wird die Objekt-Instanz freigegeben, wenn OwnsObjects = True
end;

Du prüfst, ob FOnChange zugewiesen ist, aber du prüfst nicht, ob FOnDelete zugewiesen ist und wunderst dich, dass es knallt, wenn du FOnDelete nichts zuweist?

Warum hast du das Überprüfen weggelassen? Das kann ich irgendwie überhaupt nicht nachvollziehen, und schon gar nicht die Verwunderung, dass da mal eine AV kommt. Ich würde es bei dem Code eher erwarten und mich wundern wenn keine kommt.

Bzgl. der Frage, wann die Objekt-Instanz freigegeben wird: In der überschriebenen Notify-Methode von TObjectList<T>. Wenn du also die Notify-Methode überschreibst und erst am Ende das

Delphi-Quellcode:

inherited

gibst, dann ist die Objekt-Instanz noch da.

[Sir Rufo]

Zitat:

Zitat von RWarnecke (Beitrag 1189402)

Zitat:

Zitat von stahli (Beitrag 1189400)

Ich meinte den kleinen blauen Punkt vor jeder Befehlszeile (auf den man zum Setzen eines Breakpoints klickt).
Gelegentlich fehlten die bei mir schon mal, wenn der Compiler mit meinen Units nicht zurecht kam. :stupid:

Ich habe die Klassen in einer ganz normalen Unit. Wenn ich STRG+F9 drücke, erscheinen in dieser Unit keine blauen Punkte. Ist das schlimm ?

Trotzdem steht ja immer noch meine Frage im Raum, warum FOnChange so funktioniert und FOnDelete nicht. Ist mein Sourcecode denn überhaupt richtig oder habe ich einen Fehler gemacht ?

Wenn dort keine blauen Punkte erscheinen, dann sind diese Codeteile nicht compiliert worden, werden also auch nicht aufgerufen. Wenn du die nicht brauchst, dann ist das nicht schlimm :)

[stahli]

Ich habe das Problem so verstanden, dass Rolf die Methoden definitiv zuweist:

Delphi-Quellcode:

Degree := TDegree.Create;
Degree.OnChange := TableEntryChange;
Degree.OnDelete := TableEntryDelete;

aber OnDelete dennoch nil ist.

In dem Fall kann eigentlich ja nur der Compiler ein Problem haben.

Wenn in Deiner Klasse keine Befehlszeilenpunkte stehen (und Deine Klasse benutzt Du doch!?) dann ist das bestimmt ein Problem mit dem Compiler.
Hast Du Deine Unit irgendwie kopiert und IDE und Compiler greifen auf unterschiedliche Versionen zu?

Ich würde mal schrittweise die relevanten Stellen durchlaufen...

[Sir Rufo]

Zitat:

Zitat von stahli (Beitrag 1189413)

Ich habe das Problem so verstanden, dass Rolf die Methoden definitiv zuweist:

Delphi-Quellcode:

Degree := TDegree.Create;
Degree.OnChange := TableEntryChange;
Degree.OnDelete := TableEntryDelete;

aber OnDelete dennoch nil ist.

Es ist sehr schön, wenn er dem Objekt Events zuweist, aber was hat das mit der Liste zu tun?

TDegree ist ein einfaches Objekt und befindet sich nachher in der Liste, ist aber nicht die Liste selber ;)

EDIT:

Im Beitrag #7 da hat er ein schönes Bild angehängt, wo man auch sehr schön sehen kann, das FOnDelete den Wert nil hat, und den Items (TDegree) die Events zugewiesen wurden (<>nil) :)

[RWarnecke]

Zitat:

Zitat von Sir Rufo (Beitrag 1189421)

Es ist sehr schön, wenn er dem Objekt Events zuweist, aber was hat das mit der Liste zu tun?

TDegree ist ein einfaches Objekt und befindet sich nachher in der Liste, ist aber nicht die Liste selber ;)

EDIT:

Im Beitrag #7 da hat er ein schönes Bild angehängt, wo man auch sehr schön sehen kann, das FOnDelete den Wert nil hat :)

Ich glaube jetzt habe ich es verstanden. Korrigiere mich, wenn ich falsch liege. Das OnChange funktioniert deshalb, weil die Methode von OnChange nur das Objekt ändert und nicht die Liste. Mein OnDelete ändert aber meine Liste und deshalb muss meine Methode für OnDelete expliziet der ObjectList zugewiesen werden. Richtig oder falsch ?