Turbo Delphi + Interbase-Komponenten

[IBExpert]

Zitat von globetrotter77:

@IBExpert:
1) Um beim Beispiel zu bleiben: Ist es nicht so, dass zusätzlich zum
JvUIBDataBase1 := TJvUIBDataBase.Create(Self);
noch ein
JvUIBDataBase1.Parent := Self;
erfolgen muss?

2) Irgendwo gab es unterschiedliche Meinungen dazu, ob eine so erzeugte Komponente noch im OnClose oder OnDestroy-Event mit

JvUIBDataBase1.Free;

freigegeben werden muss oder nicht. Was ist nun richtig?
Wenn überhaupt, würde ich persönlich es im OnDestroy-Event unterbringen, weil Gegenstück zu OnCreate.
Sauber programmiert wäre es aber natürlich nur dann, wenn man sich nicht mehr drum kümmern muss.

Passiert das nun automatisch, weil die Komponente quasi an die Form übergeben wurde?
Oder muss man selber dran denken?

aus meiner sicht ist es nur dann sauber programmiert wenn du selbst eine Strategie entwickelst, das alle von dir explizit erzeugten Komponenten von dir zu gegebener zeit wieder zerstörst.
Ich nutze zum beispiel fast immer eine Query Komponenteninstanz pro operation insert/update/delete (oft auch für simple selects) pro tabelle und lasse die instanz auch fast immer so lange instanziiert, wie das programm läuft.

Alle späteren Aufrufe profitieren dann von der Geschwindigkeit der bereits "prepareten" Query, d.h. der Server muss pro Befehl nicht erneut den Plan ermitteln usw. Es werden dann eben nur noch die parameter ausgetauscht und mit dem existierenden handle auf dem Server verarbeitet. Kann je nach Einzellfall durchaus 100% mehr speed bringen.

Diese einmal instanziierten Queries merke ich mir in einer Tlist und hole die bei Bedarf wieder raus, statt eine neue Instanz zu erzeugen (was so nach und nach auch einiges mehr an Speicher verbraten würde). Ich für meinen Teil weiss dann, das ich eben in diesem Fall bei Bedarf eben durch die Tlist gehe und jede Instanz rausschmeisse wenn ich das will. Die instanzen werden auch erst dann erzeugt wenn die das erste Mal gebraucht werden, sonst hat man beim Programmstart wieder unnötig lange wartezeiten. Man kann das bei Bedarf auch in eigene threads auslagern usw.

Das mit der TList macht Delphi übrigens ähnlich, siehe property components eines owners, aber die components nehmen bei Bedarf eben auch 100000 Queryinstanzen auf wenn man nicht nachdenkt und man wundert sich warum das dann so lahm ist.

Die Automatismen über den Owner, der als solcher für das zerstören der Childs zuständig ist, sind ganz nett, aber manchmal überschätzt. Man müllt da unbewusst manchmal was voll. Ich mach lieber als owner bei nicht visuellen Komponenten nil oder application. Dann kann ich auch selbst die Zerstörungsreihenfolge bestimmen (es ist manchmal nicht so nett, zuerst die database komponente zu erschiessen und danach erst die datasets, das bringt immer wieder lustige AVs). Bei visuellen Komponente (wozu aber die database nie gehört) ist dann auch der owner das formular, es sei denn, das selbe formular mißbrauche ich mehrfach und schmeiss da nach und nach die Komponenten wieder raus und erzeuge die wieder neu (was viele möglichkeiten bietet). Dann nehme ich die selbsterzeugten komponenten zumindest auch wieder in eine eigene TList auf.

Der Parent ist nur für das Zeichnen wichtig, du kannst jederzeit den Parent eines sichtbaren Controls auch zur Laufzeit verändert, so kannst du einen button von einem panel auf ein anderes verschieben mit button1.parent:=panel1; button1.parent:=panel2; usw.

Der Parent (oder besser die control instanz) kann aber zur Laufzeit zerstört werden mit z.B. freeandnil(panel2). Dein Button hat dann als parent nil, der button ist zwar noch im Speicher, aber nicht sichtbar (sehr unpraktisch in diesem Fall).