Discussion :

[Freud44]

Bonjour,

Je développe une petite application en parallèle d'une base MySQL.
Lorsque je ferme une form de mon appli, cela appele un évenement "FormClose" de builder.

Dans cet évênement, j'ai modifier le code pour que l'espace mémoire pris par la form soit libéré.

voici le code:

Code :

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

1
2
3
4
5
void __fastcall TFormAjoutFamille::FormClose(TObject *Sender,
      TCloseAction &Action)
{
       Action = caFree;        
}

Seulement voila, au moment ou la Form est quittée, l'appli plante et créée donc une exception. En supprimant l'évenement "FormClose", je ne trouve plus ce pb.

J'aimerai tout de même vider la mémoire à chaque fermeture de mes forms, donc si vous avez une solution à mon pb, je suis prenneur. ^^

Merci par avance,

[pottiez]

A mon avis c'est que tu le fait dans la Form principale, alors que ça ne doit pas être fait car lors de la fermeture de cette form, c'est toute l'appli qui se ferme, et il doit donc encore y avoir des accès pour fermer proprement l'appli, donc, caFree oui sauf sur le fenêtre principale

[Freud44]

Bah pourtant mon cafree est fait sur une Form qui n'est pas la principale...

[pottiez]

Alors c'est que t'es fenêtres doivent être construite au démarrage de l'appli, et c'est ton appli qui gère tes fenêtres, il faut donc que tu retire toutes tes fenêtres excepté la principale des fenêtres créé automatiquement dans tes options de projet (onglets Fiche)

[Freud44]

c'était ce que j'avais fait déja...

Je vois pas vraiment d'ou ca peut venir..

Je viens de refaire un essai. Et lorsque je quitte la form désirée. Rien ne plante, par contre, le fait de la ré afficher à partir de ma form principale, fait planter l'appli.

Donc c'est à la ré ouverture que ce situe le nouveau pb..

[pottiez]

Bizard comme problème, je vois pas trop d'où ça peut venir, essaye de voir ta pile d'appel lorsque ça crache

[Freud44]

oups ta pas du voir mon edit..

[pottiez]

Effectivement, désolé

si tu ne crée pas automatiquement tes fiche, fait tu bien les new et les delete a chaque fois ?

[Gilles Louïse]

Donc c'est à la ré ouverture que ce situe le nouveau pb..

Libérer la mémoire de la fenêtre signifie que la fenêtre n'existe plus, ça équivaut à delete, il est donc logique que vous ne puissiez pas rouvrir la fenêtre. Mais ai-je bien compris ?

Cette méthode a été inventée car le suicide est interdit en POO, une fenêtre ne peut pas faire un delete sur elle-même ni un objet sur lui-même. C++ Builder résout cette question en se chargeant de libérer la mémoire (d’où la notion de Owner, c’est le propriétaire qui se charge de cette libération) et, pour le cas particulier d’une fenêtre, avec ce code caFree.

Le reste est à la charge du programmeur qui doit faire coïncider ses new avec ses delete.

À bientôt
Gilles

[Freud44]

Actuellement, au lancement de ma fiche dite principale, des objets correspondants aux fiches secondaires sont instanciés (avec un new) dans le constructeur de la fiche principale.

Donc si je fais mon caFree, cela libère la fenetre secondaire concernée, sauf que si cette dernière est ré affichée, cela plante, logique l'objet est détruit.

Il faudrait donc que je modifie mon code sur la fiche principale pour que les objets correspondant aux fiches secondaires soient instanciés qu'au moment ou je décide d'ouvrir la fiche secondaire...

M'avez vous suivi?

suis je sur la bonne voie ?

merci par avance.

[pottiez]

C'est exactement ca

[Gilles Louïse]

Il faudrait donc que je modifie mon code sur la fiche principale pour que les objets correspondant aux fiches secondaires soient instanciés qu'au moment ou je décide d'ouvrir la fiche secondaire...

Le problème n'est pas l'ouverture des fenêtres, il est simplement que si vous devez faire réapparaître vos fenêtres, il faut alors ne pas utiliser caFree et ne jouer que sur leur visibilité.

C'est d'ailleurs la méthode la plus classique. On détruit rarement les objets, on les rend invisibles.

À bientôt
Gilles

[Freud44]

En fait, je me pose pas mal de question sur mon application au final, et j'essaie d'optimiser au maximum le fonctionnement de cette appli, pour ne pas surcharger la mémoire de l'ordinateur, donc je pensais supprimer les objets ne servant pas, à chaque fois, et ainsi les ré instancier si besoin.

D'ou la question du caFree, pour que l'appli ne soit pas trop lourde, étant donné qu'elle communique déja avec une base de données.

Sinon, pour optimiser, avez vous des conseils à me donner sur la programmation de mon appli, des variables à éviter, des choses à faire et ne pas faire lol...

Merci par avance,
Fred

[Gilles Louïse]

Je ne connais pas votre application et donc ne peux vous conseiller.

On ne détruit les objets que si on est obligé de le faire pour des raisons précises, si ce n'est pas le cas chez vous, ne le faites pas.

Initialisez vos pointeurs de fenêtres à NULL. Si une fenêtre est appelée, créez-la si le pointeur est NULL, sinon rendez-la visible puisqu'elle existe déjà et gardez-la en mémoire. C'est ainsi qu'on procède en général.

À bientôt
Gilles

[Freud44]

Je viens de faire un test, avec la création du pointeur de fenetre et la destruction.

En général, mes fenetres prennent 3mo en mémoire...

je trouve cela bien gros ...non?

La la fenetre générale de l'appli + la connexion à la bdd me prennent 8mo au démarrage ... Si j'instancie une fenetre mais la laisse invisible, ca me prend 3mo de plus etc...

C'est pour ca que j'essaie d'optimiser la place que prend en mémoire mon appli.

[Gilles Louïse]

Dans ce cas-là, détruisez-la au moment du Close avec caFree et mettez le pointeur à NULL à cette occasion, ainsi si le pointeur est à NULL vous réinstanciez la fenêtre en cas de rappel.

Ce qui pose problème n'est pas d'utiliser caFree, c'est de rappeler la fenêtre détruite suite à un caFree. Si la fenêtre est détruite, il faut la reconstruire. Et vous savez qu'elle est détruite si son pointeur est à NULL.

À bientôt
Gilles