Sorry, war nur ein leicht schnippiger Hinweis darauf, dass man sich über ungünstigen Code
(beim Application.ProcessMessages wird von Vielen oft davor gewarnt, aber auch Dialoge sind diesbezüglich nicht besser / noch schlimmer)
Vieles sinnlos zusätzlich kaputt machen kann.
ShowMessage im Form.OnClose/OnDestroy ist auch so ein geiler Fall. (hier nur andersrum, weil man sich gern wundern darf, wenn der Dialog oft nahezu sofort wieder geschlossen wird, da das gehende Fenster ihn mit nimmt)
Es geht selten gut aus, wenn sich in komplexere Abläufe, welche eine bestimmte Reihenfolge haben müssen,
plötzlich Pausen und die Verarbeitung von Messages ala Repaint, Timern, Tastatur, Maus usw.
reindrängeln vordrängeln.
Der Stacktrace ist auch nicht "was aufgerufen wurde", sondern "wie es zurück geht".
Man darf also nicht vergessen, dass dort die Rücksprungadresse drin steht und es eigentlich einer der Befehle davor war.
(der Debugger vertut sich auch manchmal und zeigt auf eine Codezeilen weiter unten)
Code:
A
B
C
D < hier der eigentliche Gund für den Fehler
E < hier ging es wegen dem Fehler rein
F
G < hier knallt es
E < wird nie aufgerufen
Der CallStack sagt A-B-E-F-G aber wenn man C und D wissen will, muß man manuell im Code nachsehn
oder sich über nochmaliges/mehrermaliges Auslösen und Haltepunkte+F7/F8 durcharbeiten.
Hier also irgendwann beim Aufruf von E im B zum Anfang und von da dann schrittweise weiter, bis spätestens, wo es kallt)
Auch Fehler anzeigen mit ShowMessage rächt sich nicht nur hier, sondern auch anderswo,
z.B. wenn man versucht eine Funktion von wo anders aufzurufen (Code wiederverwenden), da mit try-except versucht auf Fehler zu reagieren, um optional was Anderes zu machen.
Außer wenn in einer wirklich endgültigen Funktion ein Fehler ausgegeben werden muß, um anschließend weiter zu arbeiten,
am Besten grundsätzlich Fehler immer per RAISE abgeben.