Destroy / Entwurfzeit eigene Komponente löschen

[MarcRB75]

Hallo,

folgendes Beispiel:
ich habe eine eigene Komponente, diese installiert.

Auf einem Form platziere ich diese Komponente.
Wenn ich das Form schließe - Entwurfszeit oder wenn die EXE-Datei geschlossen wird, wird
ja destroy aufgerufen.

Aber gibt es eine Möglichkeit zu prüfen, ob die Komponente destroy aufruft, weil das Form geschlossen wurde
oder destroy aufgerufen wird, weil man z.B. Entf-Taste oder im Entwurfszeit-Menü die Komponente entfernt/löscht.

In beiden Fällen wird ja destroy aufgerufen mit dem Unterschied, dass einmal die Komponente wirklich "gelöscht, weg ist" und bei
dem anderen mal, beim einfachen schließen in der Entwicklungsebene, die Komponente nicht "richtig" gelöscht wird, sie ist ja beim nächsten mal
öffnen wieder da.

Ich hoffe, ich hab das irgendwie verständlich ausgedrückt.
Vielleicht weiß ja jemand, was ich meine und könnte mir da bitte weiterhelfen.

Vorab vielen Dank.
Marc

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

Delphi-Quellcode:

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?

[Uwe Raabe]

Das csDestroing wird in BeforeDestruction gesetzt, auch für alle Child Komponenten. Wenn also das csDestroying in Self gesetzt ist, in Owner aber nicht, dann wird Owner eben gerade nicht freigegeben.

[MarcRB75]

ahhhh ... ich verstehe... das hab ich leider gar nicht gewusst.

jetzt hab ich noch eine Frage: wie prüfe ich das?

das geht leider nicht...
if csDestroying in Owner then

oder könntest Du mir vielleicht sagen, wie ich das genau definieren müsste?

[MarcRB75]

Juhu... es klappt: :-D:witch:

Delphi-Quellcode:

procedure TTestKomponente.BeforeDestruction;
begin

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

end else
begin
  // wurde man. gelöscht...//
end;

 inherited BeforeDestruction
 end ;

DANKE AN EUCH ALLEN!!! Ich freue mich, dass das eeeendlich klappt.

[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:

Delphi-Quellcode:

inherited BeforeDestruction

Am Besten nur ein pures

Delphi-Quellcode:

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

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1535237)

Zitat:

Delphi-Quellcode:

inherited BeforeDestruction

Am Besten nur ein pures

Delphi-Quellcode:

inherited;

verwenden.

Schon weil es dann keinen Fehler gibt, wenn die Methode in der Elternklasse nicht vorhanden ist. Denn wenn sich etwas an der Klassenstruktur ändert, knallt es sonst ganz gerne an solchen Stellen.

[MarcRB75]

Vielen Dank himitsu für Deine Hilfe.

Aber bei mir funktioniert es ganz gut, vielleicht hab ich ja nur bis jetzt Glück und es klappt.

Ich habe die Komponente kopiert und auf dem selben Form platziert und es wird erkannt, dass diese neue Komponente einen neuen Namen hat und trägt sie mir in die DB ein. Das klappt schon mal ganz gut.

Dann hab ich die Komponente generell neu erzeugt, das klappt auch und
ich habe sie kopiert und in auf ein neues Form gesetzt. Das erkennt er auch und schreibt das alles in die DB rein.

Und wenn ich sie lösche, egal wie ich sie erzeugt habe, trägt er mir sie aus der DB aus.

Ein Umbenennen einer Komponente und dann das Umbenennen in der DB hab ich nicht vor, weil, wenn ich ehrlich bin auch nicht so weiß,
wie ich das realisieren kann; habe zwar einen Gedanken hierzu, aber ich will etwaige Fehlerquelle vermeiden.
Da fällt mir gerade ein: ich kann ja den Namen ruhig ändern, so lange ich den DB-Pfad im OI noch nicht zugewiesen habe.
Erst dann, wenn dieser ausgewählt/eingetragen wurde und gültig ist, schreibt er mir den Komponentennamen in die DB.

Vielleicht gab es wirklich noch keine Situation, bei dem es zu einen Crash kommt, vielleicht hatte ich Glück.
Aber selbst wenn er mir bei einer besonderen Konstellation die Komponente nicht aus der DB löscht, wäre es nicht ganz so schlimm,
weil ich diese immer noch manuell aus der DB löschen könnte, was zwar gds. nicht der Sinn ist, aber gut, dann würde sie noch drin stehen.
Ich wollte durch das Löschen nicht mehr vorhandener Komponenten vermeiden, dass irgendwelche Komponentennamen in der DB stehen, die nicht mehr
existieren. Falls da jetzt eine drin steht, die nicht mehr existent ist ... wie gesagt, das wäre nicht all zu schlimm.

Natürlich wird vorher ja auch alles geprüft, ob der DB-Pfad + DB-Name stimmen ... ich hoffe mal, es kommt nicht zu Fehlern.
Wenn während der Laufzeit z.B. die DB nicht vorhanden ist, erzeugt er mir die DB automatisch, so dass die Existenz gewährleistet ist und ich diesen
evtl. Fehler vermeiden kann. Dann entsteht wirklich eine Ausnahmesituation, so dass er die DB erstellt und den Namen der Komponente in die DB schreibt,
falls die DB wirklich nicht vorhanden sein sollte oder der DB-Pfad sich ggf. geändert hat.

Noch vielen Dank für Eure Hilfe mit mir das Problem zu lösen.

[himitsu]

Zitat:

Zitat von MarcRB75 (Beitrag 1535253)

Aber bei mir funktioniert es ganz gut, vielleicht hab ich ja nur bis jetzt Glück und es klappt.

Darum geht es ja :zwinker:

Wenn es um den Name geht, dann gäbe es auch TComponent.SetName.

Wie gesagt, wenn man nicht wirklich auf das Speichern reagiert, dann kann es in der DB dann falsch sein, wenn anschließend nicht wirklich gepsichert wird. (wobei, z.B. im Git vor dem Commit es reverten, dann stimmt es in der DB auch nicht, usw. :stupid:)

[MarcRB75]

himitsu Danke für den Tipp hinsichtlich der Namens-Änderung.
Vielleicht baue ich das noch mit ein.

Wie gesagt, nur wenn alle Konstellationen passen - aus Komponentensicht - , schreibt und löscht er den Namen in die DB rein.
Und wenn beim Öffnen zur Entwurfszeit die Komponente nicht oder noch nicht in der DB steht, schreibt er sie ebenfalls rein.

Doppeleinträge sind nicht möglich. Und zur Laufzeit ... da soll er mir ja sowieso keine Namen löschen, nur Daten auslesen und
falls, wie geschildert die Komp.Name und die DB zur Laufzeit fehlen sollte, erstellt er mir die DB und trägt den Namen ein, so dass ich zur Laufzeit
ebenfalls mit der Komponente - die u.a. Datenbankenverbindungen hat - arbeiten kann.

Naja... so war das geplant und bis jetzt zumindest funktioniert es.
Ich muss da selbstverständlich noch einiges Testen und wie so oft:
gaaanz unerwartet kommt ein Fehler, den man dann nach X-Wochen oder Monaten gar nicht erwartet und einfach nicht versteht ... ich hoffe halt, dass passiert nicht.

Naja... meine verrückten Ideen halt... versuche halt das, was ich mir im Kopf überlege, umzusetzen. Bis jetzt funkt. das aber mit meinen eigenen entwickelten Komponenten ganz gut.