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

[himitsu]

Zitat:

eine AccessViolation

Und was für eine?

Was sagt denn der debugger, wenn du dir kurz vor dem aufruf den Wert dieser Variable anzeigen läßt?

[RWarnecke]

Zitat von himitsu:

Und was für eine?

---------------------------
Debugger Exception Notification
---------------------------
Project Project14.exe raised exception class $C0000005 with message 'access violation at 0x00000000: read of address 0x00000000'.
---------------------------
Break Continue Help
---------------------------

Zitat von himitsu:

Was sagt denn der debugger, wenn du dir kurz vor dem aufruf den Wert dieser Variable anzeigen läßt?

Welchen Wert meinst Du ?

[himitsu]

Delphi-Quellcode:

  if (Assigned(FOnChange)) and (FNewRecord) and (Action <> cnRemoved) then  // hier hast'e geprüft
  begin
    FNewRecord := False;
    FOnChange(Self);
  end;
  if Action = cnRemoved then  // hier nicht
  begin
    FOnDelete(Item); // hier haltepunkt hin und schauen was in FOnDelete steht, *1
  end;

1) aber vemutlich wirklich ein "nil".
Jedenfalls sieht die Exception danach aus, da dort zur Adresse 0 (nil) gesprungen wurde und weil dort kein ausführbarer Code steht, knallt es.
(aber natürlich kann es auch noch innerhalb einer verlinkten Methode knallen, aber da sollte der Debugger ebenfalls hilfreich sein)

Der schon genannte Trick mit dem Setter würde zmindestens zeigen, ob, wann und wo dieses Property verändert wird.

[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 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 von stahli:

Hat sich Dein Compiler irgendwie verschluckt?

Weiß ich nicht.

Zitat von stahli:

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

Wie meinst Du das ?

Zitat von stahli:

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.

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

[Sir Rufo]

Zitat von 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 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 inherited gibst, dann ist die Objekt-Instanz noch da.