Test auf assigned(P) verusacht AV

[messie]

Moin,

ich habe einen TChart, in dem ich zur Laufzeit n Datenlinien erzeuge. Manchmal werden die auch gelöscht und neue erzeugt.

Die Zeile

Delphi-Quellcode:

if assigned(Chart1.Series[0]) then

erzeugt in einer bestimmten Situation eine AV. Für den Chart habe ich keine debug-dcus, kann also nicht tiefer reinschauen und genau untersuchen.

Wenn Chart1.Series[0] nil wäre, dürfte ich ja keine AV bekommen. Scheint eine ungültige Referenz auf das Objekt zu sein.

Was macht denn assigned genau und wie bekomme ich die Nachricht hinter der Schlagzeile raus?

Grüße, Messie

[Uwe Raabe]

Wenn die Anzahl der Elemente in Chart1.Series = 0 ist, verursacht der Zugriff auf Chart1.Series[0] einen Fehler. Das Assigned ist da noch gar nicht am Zug.

[mkinzler]

Überprüfe zuerst ob Chart1 existiert

[Ralf Kaiser]

Gibt es kein "Series.Count"? - Wenn ja zuerst überprüfen bevor du einen Index "Series[x]" benutzt.

Ich gehe mal davon aus, dass beim löschen einer Datenreihe das dahinterliegende Objket einfach mittels Delete aus der Collection/Liste (was ist es??) entfernt wird. In diesem Fall gibt es kein "Series[x]" mehr. Mit Assigned prüfst du ja nach, on "Series[x]" unleich NIL ist aber nicht, ob dieses Element der Collection (oder Liste) wirklich existiert.

[messie]

Zitat:

Zitat von Uwe Raabe

Wenn die Anzahl der Elemente in Chart1.Series = 0 ist, verursacht der Zugriff auf Chart1.Series[0] einen Fehler. Das Assigned ist da noch gar nicht am Zug.

Öhm, ich hatte eigentlich erwartet, dass assigned() mir eine Art geschützten Zugriff erlaubt. Dass eine Prüfung eines nachgeordneten Elements (Chart1.Series[n]) am Zugriff auf ein möglicherweise nicht referenziertes Element Chart1 scheitert, wäre mir nicht klar, weil Chart1 eigentlich vorhanden sein sollte bzw ist.

Daher auch meine Frage nach der Funktionsweise von assigned().

Grüße, Messie

[himitsu]

Nee, Assigned macht im Prinzip auch nichts Anderes, als

Delphi-Quellcode:

if Chart1.Series[0] <> nil then

[Ralf Kaiser]

Dein Problem ist, dass Assigned() den zu prüfenden Zeiger garnicht zu sehen bekommt, da er nicht da ist.

Beispiel:

OK := Assigned(Chart1-Series[4]) bedeutet wenn es genügend Elemente gibt:

Hol dir das 5. Element
Übergib das "geholte" Element an Assigned()
Weise das Ergebnis der Variablen OK zu

OK := Assigned(Chart1-Series[4]) bedeutet wenn es nicht genügend Elemente gibt:

Hol dir das 5. Element => kein Element an dieser Position vorhanden. => AV
Übergib das "geholte" Element an Assigned()
Weise das Ergebnis der Variablen OK zu


Man sieht also: Der Fehler tritt auf, bevor Assigned() überhaupt eine Möglichkeit hatte etwas zu testen!

[messie]

Also, ich habe nochmal gesucht und dann das Problem behoben.

Dazu habe ich in der Hilfe

Zitat:

Warning: Never FREE or REMOVE SeriesList elements. Use the Series.Free to remove it or use the Series.Active property to disable it.

gefunden. Warum die public Routine Chart99.SeriesList.Clear - die genau das tut - angeboten ist, ist mir schleierhaft.
Jedenfalls muss es statt eines nil setzen des n-ten Elements einen verbogenen Pointer geben, der genau zu der Zugriffsverletzung führt. Da ich keine Quellen und keine Debug-dcus habe, kann ich auch nicht in den Katakomben nachsehen, was dahinter steht.
Kann damit zusammenhängen, dass die Series sowohl als eigene VCL-Objekte als auch als Member des TChart behandelt werden. Dann wird wahrscheinlich die SeriesList nur ein PointerArray enthalten statt den Objekten selbst.

Darüber hätte ich beinahe den Glauben an die assigned-Prüfung verloren :zwinker:

Danke für die Tipps, Messie

[Ralf Kaiser]

Zitat:

Zitat von messie

Dazu habe ich in der Hilfe

Zitat:

Warning: Never FREE or REMOVE SeriesList elements. Use the Series.Free to remove it or use the Series.Active property to disable it.

gefunden. Warum die public Routine Chart99.SeriesList.Clear - die genau das tut - angeboten ist, ist mir schleierhaft.

Also dawürde ich so verstehen, dass man die Elemente der Liste nicht manuell (!!!) mit .Free freigeben sollte sondern dazu die Methoden benutzen soll die das Series-Objekt zur verfügung stellt. Wahrscheinlich werden in dem Series-Objekt noch andere Verwaltungsdaten über die enthaltenen Objekte gespeichert die beim Löschen eines der Elemente noch angepasst werden.

[messie]

Zitat:

Zitat von Alfi001

Also dawürde ich so verstehen, dass man die Elemente der Liste nicht manuell (!!!) mit .Free freigeben sollte sondern dazu die Methoden benutzen soll die das Series-Objekt zur verfügung stellt. Wahrscheinlich werden in dem Series-Objekt noch andere Verwaltungsdaten über die enthaltenen Objekte gespeichert die beim Löschen eines der Elemente noch angepasst werden.

Ich habe sie nicht manuell freigegeben, sondern Chart99.SeriesList.Clear verwendet und damit das Problem erzeugt. Jetzt nehme ich wie angegeben

Delphi-Quellcode:

Chart99.Series[i].Free

Das löscht n.m.E nur den Verweis, nicht aber das List-Objekt.

Grüße, Messie