sporadische Exception beim Freigeben von TLabels

[DenkDirNix]

Vielleicht ein WorkAround:
Vor dem Löschen eines Labels den Parent auf nil setzen.

[Gausi]

Wie gesagt, ich habe jetzt zwei Vorschläge von hier in den Code übernommen und hoffe, dass das Problem damit behoben ist.

Beim Clear der Objectlist werden die einzelnen Controls freigegeben. Dabei wird (unter anderem) der Parent auf Nil gesetzt, wodurch das Parent benachrichtigt wird, dort wird es aus den Child-Controls ausgetragen etc. pp. Beim Realign des Parents kommt es dann aus unbekannter Ursache selten (sehr selten) zu einem Problem. Wenn man das unterbindet, sollte das erledigt sein.

Die Funktion wird sehr oft aufgerufen (praktisch immer, wenn man ein Item auswählt), und ich habe nie Probleme damit beobachten können. Threads spielen an der Stelle keine Rolle - oder allenfalls indirekt, falls freigegebener Speicher "zu schnell" wieder von einem anderen Thread beansprucht wird. Dann aber sollte die Zugriffsverletzung eher an einer zufälligen Adresse passieren, und nicht an $08.
Diese Labels werden auch nicht an vielen Stellen im Code benutzt. Sie werden zur Anzeige erstellt, dargestellt, und jedes Label bekommt ein paar EventHandler (MouseEnter/Leave für Underline-Effekt, OnDoubleClick). Das wars auch schon, kein wilder Spaghetti-Code dabei.

Ein offensichtlicher Konzeptfehler liegt wohl nicht vor (sonst gäbe es andere Antworten, schätze ich ). Von daher habe ich das jetzt (erstmal) abgehakt. Nach dem nächsten Release schau ich dann mal weiter.

[TigerLilly]

Zitat von DenkDirNix:

Vielleicht ein WorkAround:

Ein Workaround ohne die Ursache zu kennen ist böse.

[himitsu]

Im großen FastMM und Ähnlichem gibt es die Möglichkeit freigegebenen Speicher mit 0 oder besser einem Pattern überschreiben zu lassen.

Dann merkt man es besser, wenn ein Objekt doppelt freigegeben wird, bzw. wenn man versucht auf Speicher zuzugreifen, welchen es nicht mehr gibt.

[DenkDirNix]

Zitat von TigerLilly:

Zitat von DenkDirNix:

Vielleicht ein WorkAround:

Ein Workaround ohne die Ursache zu kennen ist böse.

Das würde ich so grundsätzlich nicht sagen.
Dem Kunden ist es egal, ob der Entwickler auch die Ursache zu 100% analysiert hat. Hauptsache er hat ein laufendes Programm (abhängig von der Häufigkeit und Auswirkung des Fehlers, seinem subjektiven Leidensdruck).
Aber natürlich darf es nicht in "herumprobieren" ausarten, da stimme ich Dir vollkommen zu. Ein schwieriger Zielkonflikt...

[himitsu]

Problem dabei ist, dass das Problem eventuell garnicht behoben ist, sich nur gerade nicht so zeigt und dann später wieder zuhaut.

Eigentlich sollte es keine Probleme geben, wenn man etwas freigibt, da es sich selbst vorher überall deregistrieren sollte, bevor es ganz weg ist,
aber natürlich kann es hier helfen, wenn es hier irgendwo dadurch raucht, wenn man selbst die Komponente vorher aus der GUI rauszunehmen (Parent=nil).

[stahli]

Ich konnte vor Jahren ein ähnliches Problem umgehen, indem ich Controls nicht freigegeben sondern nur auf Visible := False gesetzt habe.
Die Freigabe habe ich dann später erledigt. Das Problem war wohl, dass Windows ein Control nochmal zeichnen wollte, obwohl es schon freigegeben war. Dieses hatte allerdings auch den Fokus zum Zeitpunkt der Freigabe.

[Uwe Raabe]

Sowas kann passieren, wenn das Freigeben innerhalb eines Events des Controls geschieht.