¿Por qué algunos componentes de Delphi requieren & # 8220; AOwner: TComponent & # 8221; Para construirlos?

Question

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

Por ejemplo, TXMLDocument requiere un objeto TComponent para crear una instancia.

¿Por qué es esto? Y si hay una buena razón, ¿qué debo usar allí para "hacer lo correcto"?

Answer 1

Se supone que el componente propietario gestiona todos sus componentes propios. Los componentes propios se destruyen automáticamente cuando se destruye el propietario.

Esto ayuda al desarrollador que simplemente extrae componentes de la paleta de herramientas, los suelta en el formulario y simplemente conecta los eventos para realizar 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 propietario del formulario. Cuando se cierra la aplicación, el objeto Aplicación se destruye, lo 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 vida útil del componente.

Answer 2

Todos los descendientes de 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.

Answer 3

Solo para agregar información adicional.

Cada control también tiene un padre. (Un TWinControl). Cuando el propietario se encarga de la vida, el padre se encarga 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.

Answer 4

También hay algo más a tener en cuenta. He usado más de un par de componentes de terceros que dependen de un componente Propietario que se pasa en Constructor Create, y si pasa Nil arrojará una excepción / AV.

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

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

Answer 5

El objeto no REQUIERE un tComponent se pase como AOwner. Puede pasar fácilmente a cero 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;

Answer 6

Deberías usar esto por dos razones: - el mecanismo de propiedad también es 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.).

Answer 7

Un parámetro Propietario solo es necesario para los 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 colocarlos en TForm , TFrame y TDataModule son descendientes de TComponent (que incluye TXMLDocument ).