Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 05-06-2003
craven craven is offline
Miembro
 
Registrado: may 2003
Posts: 78
Poder: 21
craven Va por buen camino
Control que crea control

Hola amigos. A ver si me podeis ayudar. Intentaré explicarme lo mejor posible. Veamos... He diseñado un control (TControl1) derivado de TGraphicControl que contiene unas propiedades, métodos, ... Pues bien, una de las propiedades es una lista de controles (TControl2), tambien diseñados por mí mismo, y derivada a su vez de TGraphicControl. El problema que tengo es que, en el primer control que os comentaba, hay un método que crea un control de tipo TControl2... En el constructor de la clase, ¿qué OWNER le paso? Esto es:

TControl2 = class (TGraphicControl)
private
....
....
public
constructor create (AOwner: TComponent) ; override ;
....
....
end ;

TControl1 = class (TGraphicControl)
private
...
controles : TControl2 ;
...
public
constructor create (AOwner: TComponent) ; override ;
...
procedure crearOtro ( ... ) ;
...
end ;

...
...
...

implementation

....
....
....

procedure TControl1.crearOtro (...) ;
begin
controles := TControl2.create ( ¿?¿?¿?¿?¿? ) ;
end ;


Gracias de antemano y un saludo para todos.
__________________
craven
Responder Con Cita
  #2  
Antiguo 05-06-2003
Avatar de __marcsc
__marcsc __marcsc is offline
Miembro
 
Registrado: may 2003
Ubicación: Girona
Posts: 577
Poder: 21
__marcsc Va por buen camino
Hola,

pues puedes pasarle Self para que tu componente de tipo TControl1 sea su dueño o puedes pasarle Owner para que el dueño sea el mismo que el del control que lo crea. De hecho incluso puedes pasarle nil siempre que en el destructor de la clase TControl1 te acuerdes de liberarlo.

Yo le podnría Self.

Saludos.
Responder Con Cita
  #3  
Antiguo 05-06-2003
craven craven is offline
Miembro
 
Registrado: may 2003
Posts: 78
Poder: 21
craven Va por buen camino
Ante todo, gracias. Lo que me has dicho ya lo he probado, pero me da el siguiente error: EInvalidOperation with message 'Control' "has no parent window"... ¿Qué piensas que puede pasar?
__________________
craven
Responder Con Cita
  #4  
Antiguo 05-06-2003
Avatar de __marcsc
__marcsc __marcsc is offline
Miembro
 
Registrado: may 2003
Ubicación: Girona
Posts: 577
Poder: 21
__marcsc Va por buen camino
Ups, ya veo

dado que TControl2 es un derivado de TGraphicControl, tienes que asignarle un parent, es decir, un objeto que contenga visualmente el objeto

Controles.Parent:= Self;

Creo que con esto te bastará.

Saludos.
Responder Con Cita
  #5  
Antiguo 06-06-2003
bitERROR bitERROR is offline
No confirmado
 
Registrado: may 2003
Posts: 33
Poder: 0
bitERROR Va por buen camino
Si sabes lo que es el override y el inherited, lo que te escribo aquí no te ayudará. De todos modos revisa que hayas incluido el inherited en tus dos controles, que creo que debe ser la causa de tu problema.

Esta es la declaración de los constructor de cada uno de tus controles (TControl1 y TControl2)

Código:
constructor create (AOwner: TComponent); override;
La claúsula override, al final de la declaración, se utiliza para poder acceder a un método heredado para modificarlo ó sobreescribirlo según las necesidades, en este caso es el método Create que viene del TGraphicControl (y que a su vez hereda del TControl y más a su vez hereda del TComponent).

El problema es que tu estás sobreescribiendo el método heredado (en ocasiones interesa, pero en tu caso no), es decir, haces el Create de tu componente pero no haces el Create de su antecesor, TGraphicControl, y a su vez impides que se hagan los Create que hereda el TGraphicControl y que deben estar asignando el Parent que te falta.

Para que se ejecute el Create del componente del que heredas, TGraphicControl, deberías implementar los Create de tu TControl1 y TControl2, incluyendo la sentencia inherited.

es decir ... asín

Código:
type TControl1 = class(TGraphicControl)
public
  constructor Create(AOwner: TComponent); override;
  .
  .
end;

.
.

implementation

procedure TControl1.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  .
  .
end;
Así, el inherited ejecutará el Create del TGraphicControl y el TGraphicControl ya ejecutará los create de sus antecesores.

Un xaludo
Responder Con Cita
  #6  
Antiguo 07-06-2003
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: may 2003
Ubicación: Guatemala
Posts: 6.254
Poder: 27
jachguate Va por buen camino
Solo que en el caso de los constructores, estos no son virtuales, por lo que no hay que poner override en su declaración.

Siempre, lo normal, dentro del constructor es llamar a un constructor de la clase padre, que a su vez llamará a otro de su ancestro y así hasta llegar al constructor de TObject, que es el que hace la reserva y la inicialización de memoria.

Podes hacer algo como:

Código:
Type
  MiClase = Class(OtraClase)
  public
    Constructor Create(Parametro1, Parametro2 : Tipo);
    Destructor destroy; override;
  end;
Fijate que el destructor si es virtual, y es imprescindible, si lo vas a integrar a la VCL que pongas el override para que funcione correctamente, pues los owners llamarán al método Destroy para liberar la memoria, y si no has puesto override, tu clase no tendrá oportunidad de liberar la memoria o recursos que reserve por si mismo.

Lo normal luego, es hacer algo como:

Código:
Constructor MiClase.Create(Parametro1, Parametro2 : Tipo);

Begin
  // lo primero es llamar a un constructor de la clase padre
  inherited Create(ConSusParametros);
  // luego, la inicialización normal del objeto
End;

Destructor MiClase.Destroy;

Begin
  // primero, libero memoria, recursos, notificaciones, etc.
  CualquierCosa;
  // por último, llamo al destructor del ancestro...
  inherited;
End;
Es importante mencionar que el método destroy no lleva parámetros.

Es una convención llamar al constructor Create, pero no es necesario.... lo podes llamar como querras. En realidad, también al destructor, pero insisto, si lo vas a integrar a la VCL, también debes llamarlo Destroy.

Hasta luego.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 03:08:52.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi