Discussion :

[Paul TOTH]

Vous savez qu'un composant peu avoir un Parent et/ou un Owner...petite question piège pour voir si vous avez tout suivi

avec le code ci-dessous, combien de boutons seront détruit lors de la destruction de la fenêtre ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
  private
    { Private declarations }
    Button2 : TButton;
    Button3 : TButton;
    Button4 : TButton;
  public
    { Public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm} // déclare TButton1
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  Button2 := TButton.Create(Self);
 
  Button3 := TButton.Create(Self);
  Button3.Parent := Self;
 
  Button4 := TButton.Create(nil);
  Button4.Parent := Self;
end;

[cincap]

J'aurai dit les 4 automatiquement avec

Dans le destroy button2.free;

@+,

Cincap

[Yurck]

Excusez moi d'avoir répondu je n'avais pas bien vu à qui était adressé ce petit sondage.
Du coup j'ai été surpris du résultat.
Le débutant ne répond pas il pose d'abord la question sur DVP après il conteste, et enfin il réfléchit

[Linkin]

Euh... idem

[cincap]

Button 2, 3 et 4 se créent, self indique comme propriétaire form1, button4 indique Nil donc pas de propriétaire !

Maintenant, je suis débutant j'ai peut être loupé quelque chose.

@+,

Cincap

[Paul TOTH]

Alors, je précise que la question se pose à tous, vu que je me suis fais avoir personnellement

[peter27x]

Alors, je précise que la question se pose à tous, vu que je me suis fais avoir personnellement

Salut, en fait je crois que AOwner ne signifie pas destruction liée, alors que Parent oui... c'est pas ça ?

En gros le conteneur peut être différent du père, et à priori en conception objet la destruction se fait père -> enfants. Mais pas conteneur je suppose, qui est juste l'objet qui contient, mais pas le père. Enfin disons que ça peut être les deux à la fois bien sûr, mais là avec Delphi c'est pas obligatoire. (Dans d'autres langages peut être aussi remarques).

[Aka Guymelef]

Haaaaa ben je me suis fait avoir aussi.

Merci Paul d'avoir partagé cela, et pour les autres tomber les à priori, vérifiez par vous-même

[Paul TOTH]

Salut, en fait je crois que AOwner ne signifie pas destruction liée, alors que Parent oui... c'est pas ça ?

En gros le conteneur peut être différent du père, et à priori en conception objet la destruction se fait père -> enfants. Mais pas conteneur je suppose, qui est juste l'objet qui contient, mais pas le père. Enfin disons que ça peut être les deux à la fois bien sûr, mais là avec Delphi c'est pas obligatoire. (Dans d'autres langages peut être aussi remarques).

Alors on peut se référer à l'aide en ligne de Delphi pour éclairer les choses...prenons Delphi 5 que j'ai sous la main...

La propriété Owner permet de connaître le propriétaire d'un composant. Lorsqu'un composant en possède un autre, la mémoire du composant possédé est libérée quand la mémoire du propriétaire est libérée

Ne confondez pas la propriété Parent déclarée dans TControl avec la propriété Owner déclarée dans TComponent. Le Parent d'un contrôle est toujours un contrôle fenêtré contenant visuellement le contrôle en question et qui est responsable de l'écriture du contrôle dans un flux lorsque la fiche est enregistrée. Le Owner d'un composant est le composant qui a été transmis en paramètre dans le constructeur et qui contrôle quand le composant est libéré.

Alors ? d'autres réponses dans ce sondage ?

[peter27x]

Alors on peut se référer à l'aide en ligne de Delphi pour éclairer les choses...prenons Delphi 5 que j'ai sous la main...





Alors ? d'autres réponses dans ce sondage ?

OK donc Delphiement parlant c'est l'inverse, le AOwner est le père, et le Parent juste le conteneur... donc ça devrait être le Aowner qui prime pour la destruction automatique de tes 4 buttons de malheur.

[Paul TOTH]

Bon, après avoir consulté les sages et l'aide en ligne, nous allons demander son avis à Delphi lui même

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
type
  TButton = class(StdCtrls.TButton)
  public
    destructor Destroy; override;
  end;
 
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
  private
    { Private declarations }
    Button2 : TButton;
    Button3 : TButton;
    Button4 : TButton;
  public
    { Public declarations }
    destructor Destroy; override;
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
var
  gCount : Integer = 0;
 
destructor TButton.Destroy;
begin
  Inc(gCount);
  inherited;
end;
 
destructor TForm1.Destroy;
begin
  inherited;
  MessageBox(0,Pchar(IntToStr(gCount) + ' Buttons'),'Buttons',0);
end;
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  Button2 := TButton.Create(Self);
 
  Button3 := TButton.Create(Self);
  Button3.Parent := Self;
 
  Button4 := TButton.Create(nil);
  Button4.Parent := Self;
end;

et la réponse est..."4 Buttons" !!!!!!!!!!!!!

Mais qui est l'assassin de Button4 ?

[ShaiLeTroll]

Lol, J'ai répondu trop vite, j'avais pas vu Button1, oups , j'ai répondu 2, mais c'est c'est évidemment 3 euh non 4 ... ça sera pas CleanupInstance qui appele Finalize, l'assassin mystère ou alors un petit IInterface ajouter dès TComponent, en fait, le Owner il sert à quoi si derrière il y a quand même le compteur de référence ?

Sinon, Owner c'est propriétaire ... et donc pas conséquence, il peut détruire ce qu'il possède, après tout c'est son droit, voire même son devoir ...
Pour la Parent, ben il va pas tuer son fils, sinon c'est la prison ...

Le plus drôle serait de changer le Owner de Button1 via RemoveComponent, la Référence Button1 passe à nil !
Button1 a toujours Self comme Parent, donc toujours visible mais jamais libéré !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Self.RemoveComponent(Button1);
if Button1 = nil then
 ShowMessage('Ah ben ça alors !');

[Yurck]

et la réponse est..."4 Buttons" !!!!!!!!!!!!!

Mais qui est l'assassin de Button4 ?

Je doute de ta réponse et donc de ta démonstration

N'aurais tu pas une seule fiche dans ton application ???

Create de nil affecte L'application comme propriétaire du coup ....

à voir

[Paul TOTH]

Pour la Parent, ben il va pas tuer son fils, sinon c'est la prison ...

Va raconter ça à TWinControl !!!

Code delphi :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
destructor TWinControl.Destroy;
var
  I: Integer;
  Instance: TControl;
begin
// ...
  I := ControlCount;
  while I <> 0 do
  begin
    Instance := Controls[I - 1];
    Remove(Instance);
   Instance.Destroy; // IL LE FAIT !
    I := ControlCount;
  end;
//  ...
  inherited Destroy; // l'Owner n'interviendra qu'ici !
end;

J'ai découvert cela tout à fait par hasard avec le code d'un collège...genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
type
  TForm1 = class(TForm)
    Frame1: TFrame1;
  end;
// ...
  TFrame1 = class(TFrame)
  private
   FPanel : TPanel;
  public
   constructor Create(AOwner: TComponent);
   destructor Destroy; override;
  end;
 
constructor TFrame1.Create(AOwner: TComponent):
begin
  inherited;
  FPanel := TPanel.Create(Self);
  FPanel.Parent := Self.Parent;
end;
 
destructor TFrame1.Destroy;
begin
  FPanel.Free; // inutile, mais n'aurait pas du planter...mais si :)
  inherited;
end;

le Free de FPanel ne sert à rien...mais comme c'est la fiche qui le détruit, quand on arrive au Destroy de TFrame1, FPanel est devenu invalide !!!

[Yurck]

Va raconter ça à TWinControl !!!

Code delphi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
destructor TWinControl.Destroy;
var   I: Integer;
  Instance: TControl;
begin
  ....
  Remove(Instance);
  Instance.Destroy; // IL LE FAIT ! 
  ....
end;

Bon bah mon monde de certitudes s'écroule de nouveau.
Finalement 2009 ressemble à 2008 il va falloir tout reconstruire.

Quelle vie !!

[Aka Guymelef]

Ce n'est pas spécifique à D2009, pour preuve je cite mon aide Delphi 7 :

La propriété Parent déclarée dans TControl est similaire àla propriété Owner déclarée dans TComponent, dans le sens où le parent d'un contrôle libère le contrôle de même que le propriétaire d'un composant libère ce composant. Néanmoins, le parent d'un contrôle est toujours un contrôle fenêtré contenant visuellement le contrôle en question et est responsable de l'écriture du contrôle dans un flux lorsque la fiche est enregistrée. Le propriétaire d'un composant est le composant transmis comme paramètre dans le constructeur et, s'il est affecté, lance le processus d'enregistrement de tous les objets (y compris le contrôle et son parent) lorsque la fiche est enregistrée.

Donc la réponse est bien 4 car :

1. Button1 est déposé sur la fiche, son Owner est donc implicitement Form1.
2. Button2 est créé avec Owner Self, donc Form1.
3. Button3 idem. L'affectation du Parent est redondante au niveau du Owner.
4. Button4, créé sans Owner mais est ensuite affecté comme Parent Self, donc deviens son Owner.

[sjrd]

Hum... Je me suis fait avoir aussi.
Ca m'évitera probablement un jour des problèmes

[edam]

et si tu garde la question pour Button4, on utilisant un composant non visuelle,

[guillemouze]

La propriété Parent déclarée dans TControl est similaire à la propriété Owner déclarée dans TComponent, dans le sens où le parent d'un contrôle libère le contrôle de même que le propriétaire d'un composant libère ce composant(...)

Question subsidiaire :
Si on a 2 formes non principales F1 & F2, contenant (=parent) respectivement un bouton B1 & B2, que se passe t'il si on effectue

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
B1.parent := F2; //intialement F1
B2.parent := F1; //intialement F2

et qu'on libere F1 ?

theoriquement, F1 est le owner de B1, mais F2 est son parent. Donc F1 doit liberer B1 et le retirer le F2 !

[ShaiLeTroll]

C'est très décevant, cette histoire, jusqu'à présent, Owner et Parent était dans ma tête deux notions différentes, ... on sent la grosse faille dans le sytème de libération par l'Owner qu'ils ont du suppléer par celle du Parent ... ou alors, il y a un lien avec les handles Windows (TWinControl <=> TGraphicControl), un fils ne peut pas exister si son parent a été libéré (donc son handle avec) sans provoquer une installabilité dans le GDI windows genre une OSError 1400 lorsque l'on joue trop avec les fenêtres dans un Thread ...