Discussion :

[oiapoque]

Bonjour,

A la fermeture d'une fenetre, je tente de détruire tout ses composant en faisant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
i := ComponentCount-1;
  While i > 0 do begin
        if Components[i].Owner.Name = Self.Name then Begin
          try
           Components[i].Destroy;
           i := ComponentCount-1;
          except
          end;
 
        end Else
          Dec(i);
  End;

L'erreur "EAccessViolation" apparait, Mes composants sont créés dynamiquement, et il semble que cette erreur vienne d'un acces à la memoire qui n'existe pas...
mon application travail en local et en reseau, il se trouve que cett erreur ne se produit qu'a la fermeture d'un dossier reseau (mais je ne vois pas pourquoi).

Petit test réalisé, les EAccessViolation semble apparaitre pour la destruction de composant de type "PageCOntrol"

Code :

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

1
2
 
Components[i].name;

m'a retourné des noms de composant de type: PC_4, PC_3 PC_2...
mais je n'arrive pas à les identifier d'avantage. Y-a-t-il une methode pour trouver d'avantages d'infos sur ses composants?

quels tests puis-je faire pour resoudre ces problemes d'acces memoire ou trouver quels composants son innaccessibles???

merci pour toute idee pour avancer

a bientot

eric

[evarisnea]

d'après ton code, tu détruis tous les composant possédés par ta fenêtre, et là je me demande bien pourquoi ?
car tu dois savoir que ta fenêtre libérera elle même tous les composants qu'elle possède à sa destruction. si tu n'essaie pas de libérer tes composants a la fermeture y a-til toujours une erreur ?

[Philippe Gormand]

Bonjour.

Si les comosants sont déclarés dans la partie Class de la fiche, il ne faut pas appeler leurs méthodes Destroy. Dailleur, Destroy ne doit jammais être appellé directement. C'est la méthode Free qui s'en charge. Mais dans le cas où les composant sont déclaé de cette façon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
    TForm1 = class(TForm)
 
 
     public
        Image1 : TImage;
        Edit1     : TEdit;
 
 
......

Ils appartiènent au conteneur qu'est la fiche (TFom1). A la fermeture de la fiche les comosant sont automatiquement dédruis. Si un au appel à la méthode Destroy ou Free, il y a forcément une violation d'accès.

[oiapoque]

si tu n'essaie pas de libérer tes composants a la fermeture y a-til toujours une erreur ?

L'erreur apparait à la libération de la Fiche (EcDossier) contenant les composants:

Code :

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

1
2
3
4
5
6
7
8
9
 
     try
       EcDossier.Free;
       EcDossier := nil;
     Except
       EcDossier.Destroy;
       EcDossier := nil;
//       ShowMessage('Attention destruction Dossier Level 2');
     end;

aucun code n'est de moi, je tente seulement de debugger un petit peu un programme avec mes faibles connaissances Delphi, mais j'en apprend tous les jours sur ce forum !! merci

Dailleur, Destroy ne doit jammais être appellé directement. C'est la méthode Free qui s'en charge.

oui j'ai bien vu çà, mais ds la boucle de destruction de composants, le resultat est le même

[Philippe Gormand]

Donne le code où est déclaré ecDossier, et le code où il est créé (méthode Creat).

A+

[Bejaia-In]

Est-ce que à un moment donné, dans le code, il-y-a création de composants ?
Si oui ceux-là seulement doivent être libérés, sinon tu ne dois détruire rien du tout.

Code :

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

1
2
 EcDossier.Free;
 EcDossier := nil;

Quelle est cette bizarerie ? libérer un composant pour lui donner une valeur nil ?

[oiapoque]

Est-ce que à un moment donné, dans le code, il-y-a création de composants ?
Si oui ceux-là seulement doivent être libérés, sinon tu ne dois détruire rien du tout.

Quelle est cette bizarerie ? libérer un composant pour lui donner une valeur nil ?

oui c'est bizarre hein, d'ailleurs l'auteur du programme a répété cette bizarrerie partout

enfin bref, j'ai modifié la boucle de destruction des composants de ma Fiche qui sont créés dedans, ils sont tous detruits (libérés? je suis ne pas au point dans la rhétorique) sans erreurs
et dans mon Main, à la place de

Code :

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

1
2
3
 
EcDossier.Free;
EcDossier := nil;

je fais seulement

Code :

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

1
2
 
EcDossier := nil;

et visiblement je n'ai plus d'erreur
dans l'immédiat, çà me suffira, mais si quelqu'un a un peu de théorie sur la destruction d'objets/free/destroy et comment faire un code propre ds ces situations, je suis preneur car là je ne comprend pas tout


pour Philippe Gormant je ne peux pas laisse le code du FormCreate car il est bcp trop long et sans commentaires, mais il créée essentiellement des boutons et des onglets en nombre TRES consequent....


merci a tous

[Philippe Gormand]

Si les composants sont déclarés dans la partie Class de la fiche, il ne faut pas appeler leurs méthodes Destroy ni la méthode free. Dailleur, Destroy ne doit jammais être appellé directement. C'est la méthode Free qui s'en charge. Mais dans le cas où les composant sont déclaé de cette façon :

Code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
type
    TForm1 = class(TForm)
 
 
     public
        Image1 : TImage;
        Edit1     : TEdit;
 
 
......

Ils appartiènent au conteneur qu'est la fiche (TFom1). A la fermeture de la fiche les composants sont automatiquement dédruis. Si un autre appel à la méthode Destroy ou Free, il y a forcément une violation d'accès.

Code :

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

1
2
 
EcDossier := nil;

est parfaitement inutile.

[oiapoque]

Mes composants n'appartiennent pas à la TForm qui les créé, ils ne sont donc pas détruits automatiquement.

Merci bcp pour les précisions!!

Code :
EcDossier := nil;est parfaitement inutile.

C'est bien vrai !!!


Merci a tous! Courage et Bonne Humeur !

[e-ric]

Mes composants n'appartiennent pas à la TForm qui les créé, ils ne sont donc pas détruits automatiquement.

Merci bcp pour les précisions!!



Citation:
Code :
EcDossier := nil;est parfaitement inutile.


C'est bien vrai !!!


Merci a tous! Courage et Bonne Humeur !

Bonjour

je ne suis pas sûr d'avoir tout suivi mais ce genre de code doit amener à la suspicion, il est en général le signe d'une variable globale, l'affectation à nil permet de marquer l'allocation/la désallocation de l'objet de manière simple :

Code :

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

1
2
3
4
5
6
 
if not Assigned(ECDossier) then
  ecDossier := TEcDossier.Create;
// plus loin dans l'application ...
ecDossier.Free;
ecDossier := Nil;

Dans ce cas, l'affectation à nil a du sens et est même indispensable.
Cependant je ne sais pas si cela correspond à la situation dans le code de oiapoque. C'est juste une remarque.

En ce qui concerne la remarque

Ils appartiènent au conteneur qu'est la fiche (TFom1). A la fermeture de la fiche les composants sont automatiquement dédruis. Si un autre appel à la méthode Destroy ou Free, il y a forcément une violation d'accès.

C'est partiellement vrai, les composants bien écrits doivent intégrer cette situation et informer leurs conteneur de leur libération (ce qui est le cas des composants Borland) qui doit être suffisament initelligent pour ne pas chercher à libérer des composants déjà détruits.
Sinon, je ne vois pas pourquoi l'inverse serait valable à savoir qu'un conteneur puisse libérer des objets créés à la volée. Cela nous amènerait à une distinction forte entre composants instanciés automatiquement par la fiche et ceux créés à la volée par code, cette distinction ne va pas dans le sens de la robustesse des applications.

cdlt

e-ric

[Philippe Gormand]

Ouï ! Ouï ! Ouï !

C'est partiellement vrai, les composants bien écrits doivent intégrer cette situation et informer leurs conteneur de leur libération (ce qui est le cas des composants Borland) qui doit être suffisament initelligent pour ne pas chercher à libérer des composants déjà détruits.
Sinon, je ne vois pas pourquoi l'inverse serait valable à savoir qu'un conteneur puisse libérer des objets créés à la volée. Cela nous amènerait à une distinction forte entre composants instanciés automatiquement par la fiche et ceux créés à la volée par code, cette distinction ne va pas dans le sens de la robustesse des applications.

L'objet TForm est non seulement un conteneur, mais c'est le Thread principal.
Tout object déclaré dans l'objet TForm (le Thread principal ) est automatiquent détruit à la destruction (méthode Release ou Close) de la fiche. Cela fait partie des automatismes de DELPHI.

Il suffit de faire quelque tests pour le constater. L'aide de DELPHI est très claire et très précise sur le sujet.

Un TPanel par exemple, est un conteneur mais pas le Thread principal donc pas le conteneur principal. La gestion en est différente.

Cela nous amènerait à une distinction forte entre composants instanciés automatiquement par la fiche et ceux créés à la volée par code, cette distinction ne va pas dans le sens de la robustesse des applications.

Complètement faux. Cela permet justement une grande puissance de programmation, et une grande sécurité (à condition de bien la gérer).

[Bejaia-In]

Voici l'implémentation de la méthode Free de tout objet :

Code :

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

1
2
3
4
5
procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

on voit bien qu'affecter la valeur nil au composant est du pareil au même que d'appeller la méthode Free.

[Philippe Gormand]

on voit bien qu'affecter la valeur nil au composant est du pareil au même que d'appeller la méthode Free.

Mais non. La methode free test la valeur de NIL de l'objet pour le détruire. C'est à dire, libérer la mémoire et supprimer l'instance de l'objet en apellant la Méthode Destroy. Si on affect la valeur NIL à un objet avant d'appeller la méthode Free, Free ne pourra plus appeller la méthode Destroy.

Code :

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

1
2
3
4
5
6
 
procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

C'est pourtant clair.
Nil ne fait que que supprimer le référencement à un pointeur.
Un objet est un pointeur. Si il a été détruit, son référencement a forcément la valeur NIL.