Destroy / Entwurfzeit eigene Komponente löschen

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

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:

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

[jaenicke]

Zitat von himitsu:

Zitat:

inherited BeforeDestruction

Am Besten nur ein pures 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 von MarcRB75:

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

Darum geht es ja

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

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