visual que library definicion componente component delphi vcl

que - tms vcl delphi



¿Por qué algunos componentes de Delphi requieren "AOwner: TComponent" para construirlos? (7)

Debes usar esto por dos razones: el mecanismo de propiedad también se encuentra como un tipo de sistema de recolección de basura; el mecanismo de propiedad es importante en el proceso de serialización de Delphi (Stream.ReadComponent / WriteComponent, etc.).

Parece completamente irrelevante exigir a un TComponent como propietario que cree un objeto de algún tipo. ¿Por qué hay tantos componentes Delphi que requieren esto?

Por ejemplo, TXMLDocument requiere un objeto TComponent para instanciar.

¿Por qué es esto y si hay una buena razón, qué debería estar usando allí para "hacer lo correcto"?


Se supone que el componente propietario debe administrar todos sus componentes propios. Los componentes de propiedad se destruyen automáticamente cuando el propietario es destruido.

Esto ayuda al desarrollador que simplemente arrastra los componentes de la paleta de herramientas, los coloca en el formulario y simplemente conecta los eventos para hacer su trabajo sin preocuparse por administrar la vida útil de los componentes.

El formulario es el propietario de todos los componentes incluidos en él. El objeto Aplicación es el propietario del formulario. Cuando se cierra la aplicación, se destruye el objeto Aplicación, que a su vez destruye los formularios y todos los componentes.

Pero el propietario no es realmente necesario cuando se crean componentes. Si pasa Nil al parámetro, el componente se creará sin un propietario y en este caso será su responsabilidad administrar la duración del componente.


Solo para agregar algo de información extra.

Cada control también tiene un padre. (A TWinControl). Cuando el propietario se ocupa de la vida, el padre se ocupa de mostrar el objeto.

Por ejemplo, un formulario tiene un panel y el panel tiene un botón. En ese caso, el formulario posee el panel y el botón. Pero el formulario es el padre del panel y el panel es el padre del botón.


También hay algo más que tener en cuenta. He utilizado más de un par de componentes de terceros que se basan en un componente Propietario que se pasa en el Constructor Crear, y si pasa en Nil lanzará una excepción / AV.

El resultado neto es que estos componentes funcionarán bien cuando utilice visualmente dentro del IDE pero causará problemas cuando se creen en tiempo de ejecución.

La causa de estos problemas es, en cierto sentido, un mal diseño. Nada en las reglas establece que no puede / no debe pasar en NIL como el parámetro aOwner.


Todos los descendientes TComponent requieren Propietario, se define en el constructor TComponent. El componente Propietario es responsable de destruir todos los componentes Propios.

si desea controlar el tiempo de vida, puede pasar nil como parámetro.


Un parámetro Owner solo se necesita para descendientes TComponent , ya que es un parámetro del constructor TComponent . Todos los componentes a los que se puede acceder en tiempo de diseño para caer en las TForm , TFrame y TDataModule son descendientes TComponent (que incluye TXMLDocument ).


El objeto NO REQUIERE que un tComponent se pase como AOwner. Puede pasar fácilmente a esto y manejar la destrucción usted mismo. Muy a menudo, tiendo a usar esta técnica para rutinas localizadas donde el componente que se usa no se usará fuera del método actual. por ejemplo:

Procedure TForm1.Foo; var XmlDoc : tXmlDocument; begin XmlDoc := tXmlDocument.Create(nil); try // do processing of the XMLDoc here finally FreeAndNil(XmlDoc); end; end;