Zitat von
SirThornberry:
Wenn Komponenten dynamisch erzeugt werden ist der Owner oftmals nil weil er nicht benötigt wird -> denn Dinge die man selbst anlegt/instanziert räumt man auch selbst wieder auf und ist somit nicht auf den Owner angewiesen der teilweise in der Objecthierarchy auch nicht vorhanden ist die man sich im Konzept überlegt hat.
Ergänzung:
Wenn es sich aber - so wie hier - um eine visuelle Komponente handelt, spricht doch nichts dagegen, den Owner vorzusehen. Dazu passend spricht auch nichts dagegen, der zur Laufzeit erzeugten visuellen Komponente als Owner das Form zu übergeben, auf dem die Komponente angezeigt wird. Hat auch den Vorteil, dass sie in der Eigenschaft Components des Form eingetragen wird, was oftmals nützlich ist.
Zudem sagt die Hilfe folgendes:
Zitat:
"Der Eigentümer ist für das Laden und Speichern der published-Eigenschaften seiner untergeordneten Komponenten verantwortlich."
Ich weiß zwar gerade nicht so wirklich, was das bedeutet, aber es klingt nicht unwichtig.
Ich sehe daher nicht viele Gründe, einen Owner nicht vorzusehen. Möchte man keinen übergeben bei Txxx.Create(aOwner), so übergibt man eben NIL.
Und
da z.B. fangen die Probleme dann an, wenn man - so wie speziell hier geschehen - den
Owner pauschal auch zum Parent erklären möchte. Denn das kann (trotz oder gerade wegen Typecast auf TWinControl) schön schiefgehen, wenn eben der Owner
kein TWinControl ist.
Ich denke, SirThornberry meint das auch so; ich wollte es nur noch mal etwas verdeutlichen.
