Destroy / Entwurfzeit eigene Komponente löschen

[himitsu]

Und was soll das für einen Unterschied machen, bzw. wozu muß man das wissen?
Die Komponente wird so oder so freigegeben, hat all ihre Ressourcen freizugeben und hat eigentlich nichts zu tun, außer gelöscht zu werden.

if Assigned(Owner) and (csDestroying in Owner.ComponentState) then

[MarcRB75]

Vielen Dank für Deine Antwort.
Ich probiere das gleich mal aus.

Nun, ich möchte "neue" Komponenten in die Datenbank schreiben, wenn diese in der Entwurfszeit auf dem Formular plaziert werden.

Diese Komponenten soll Festlegungen in der Laufzeit speichern, wenn diese in der EXE bearbeitet wird und später, wenn das Form wieder erzeugt wird,
sollen automatisch die Festlegungen aufgerufen werden. Ja natürlich kann/könnte man das auch anders lösen, aber ich wollte es
in die Datenbank schreiben, vor allem, weil einige Festlegungen getätigt werden können und damit andere Funktionen jeweils verbunden sind.

Beim Erzeugen des Form wird die DB aufgerufen, sucht nach dem Namen der Komponente und lädt alle Festlegungen auf.

Wenn in der Entwurfszeit jetzt eine Komponente gelöscht wird, soll auch automatisch die gespeicherte Komponente/Name aus der DB gelöscht werden.
Die anderen bleiben erhalten und sollen nicht gelöscht werden.
Deshalb müsste unterschieden werden, ob die Komponente "manuell", also in der Entwurfszeit gelöscht wurde oder während dessen, wenn die EXE selbst bzw. die Entwurfszeit geschlossen wird.

[MarcRB75]

if Assigned(Owner) and (csDestroying in Owner.ComponentState) then ..
geht leider nicht.

[himitsu]

Doch.

[MarcRB75]

ja, es geht schon, aber leider nicht für das, was ich vor hatte.

[Uwe Raabe]

Beim Schreiben der DFM hat eine TComponent das csWriting in ComponentState. Das könnte ein Trigger für das Create/Update in der DB sein.

Aber wie bekommt man das da wieder raus, sollte die Komponente dann mal aus dem Form wieder gelöscht werden?

[MarcRB75]

Vielen Dank für Deine Antwort.
Er schreibt alles wunderbar in die Datenbank. Das passt.
Aber wenn manuell während der Entwurfszeit die Komponente gelöscht wird, sei es mit der Entf-Taste/Strg.+X müsste das vorher abgefangen werden,
damit er beim destroy weiß ... diese Komponente muss aus der DB gelöscht werden. So meinte ich das eigentlich....

[Uwe Raabe]

Nur so ins Blaue: Du könntest ComponentState auf csDestroying testen und das auch für Owner tun. Wenn letzteres nicht der Fall ist, wird nur die Komponente freigegeben.

[MarcRB75]

Danke für den Tipp... jaaa... das hatte ich mir auch schon überlegt... aber owner wird doch nach der Componente "zerstört", somit wird owner nicht den Status der Zerstörung haben, ober? Oder erhält owner den Status der Zerstörung, wenn zuerst andere Componenten "zerstört" werden müssen?

[himitsu]

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 ...