Danke schonmal für die Antworten.
Nein, Threads habe ich an der Stelle nicht. Ich klicke auf ein Element in einer VirtualTreeView, und zeige im "onClick" die Elementeigenschaften an. Ein Teil davon ist das Erzeugen dieser Labels. Ich nutze zwar durchaus mehrere Threads für einige Hintergrundarbeiten, aber die Labels sind rein
VCL-Thread. das würde auch öfter knallen, denke ich.
FastMM habe ich mal probiert (du meinst doch das hier, oder?
https://github.com/pleriche/FastMM4). Tatsächlich zeigt der mir am Ende an, dass etwas doppelt freigegeben wird, aber das hat hiermit nichts zu tun - da gibt es noch ein Problemchen im Finalize einer
Unit. Wenn ich das (erstmal Quick&Dirty, so ganz gefällt mir die Lösung noch nicht) ins OnDestroy der MainForm verschiebe, gibt es keine solche Meldung mehr.
Die Label liegen auf einem Panel (bzw. auf einer eigenen Ableitung davon). Dieses Panel bleibt aber zur Laufzeit erhalten. Die Objekte in der Liste sollten also nicht "von außen" gelöscht werden können. Die TComponentList schaue ich mir aber auch nochmal an. Ob dadurch der Fehler behoben wird, kann ich aber ohne Reproduktionsweg nicht so richtig testen ...
TComponents haben aber ein intenes Notifications-Systen, womit man sich informieren lassen kann, wenn es freigegeben wird. (das nutzt der Owner, Parent und z.B. eine ComponentList)
Jep, das wird hier ja auch getriggert. Durch das Clear der ObjectList wird für jedes Objekt (=TLabel), das jetzt zerstört werden soll, das Parent informiert. Das Parent löscht die Referenz darauf, und ruft dann noch AlignControls auf (auch wenn das hier nicht nötig wäre, da die Labels alle alNone sind). Und dabei kommt die
Exception. Meine Vermutung war also, dass das Parent doch noch Referenzen auf Objekte hat, die die Liste schon fertig zerstört hat. Aber das sollte nicht passieren, wenn ich mir den Code von TObjectList.Clear so anschaue und von all dem Gedöns, was da dranhängt ...