Was du im BeforeDestruction machst, sollte so aber auch im Destroy gehen.
* Ausschneiden und neu einfügen, ist auch ein Löschen
* Komponente einfügen, aber dann die Form nicht speichern, ist auch ein Löschen
* Komponente löschen und nicht speichern, dann hast du sie aus der
DB gelöscht, aber eigentlich ist sie noch da.
* irgendwas machen und Delphi stürzt ab, schon ist es auch wieder falsch
* nur weil BeforeDestruction aufgerufen wurde, muß es nicht sein, dass die Komponente wirklich gelöscht wird (hier irgendwo eine
Exception oder Abort und schon wird Destruction nicht aufgerufen und auch nichts freigegeben)
* ...
Fazit:
* Auf Löschen und Erstellen zu reagieren, ist eine saublöde Idee, wenn es um externe Daten geht.
* Auf das
Speichern der DFM Streamen der
DFM zu reagieren, ist auch eine saublöde Idee. (nur weil die
DFM gespeichert der Stream generiert wird, wird noch lange nicht die
DFM-Datei gespeichert ... z.B. Alt+F12 oder beim automatischen Entladen, wenn man das DesignTime-
Package kompiliert, seit einigen Delphi-Versionen, oder eine
Exception in einer anderen Komponente, welche das Streamen/Speichern abbricht, oder ...)
* Also ab zur OpenToolsAPI (OTA) und dort "wirklich" auf das Speichern des Projektes reagieren, bzw. der
Unit.
Zitat:
inherited BeforeDestruction
Am Besten nur ein pures
inherited;
verwenden. (auch Parameter müssen dann nicht geschrieben werden, wenn man nicht "andere" Variablen an die Parameter übergeben will, als wie oben deklariert)
* keine Fehler durch Copy&Paste-Errors (falschen Methodennamen kopiert)
* oder weil ausversehn den falschen Namen geschrieben, bzw. durch die Codevervollständigung gewählt/geändert
* oder den Code in eine andere Methode verschieben
* oder ...