Discussion :

[od.dev]

Bonjour à tous,
Une petite question d'école :
En cliquant sur un bouton de la form principale, je créé une form contenu dans une dll.
Dans cette fiche, je déclare une variable globale que j'initialise à 0.
Je travail avec cette variable qui s'incrémente, puis, en cliquant sur un bouton de cette form, je détruit celle-ci par "Release".
Jusque là, tout me semble normal.
Mais quand je recréé cette même form pour retravailler dedans, sans avoir quitté l'appli, il ne réinitialise pas la variable globale !
bien que j'ai détruit la form avec "Release" !
Donc là, je ne comprends plus, il ne réinialise pas les variables globales à la création de la fiche après que celle-ci ait été créée une première fois, même si on détruit cette fiche !
Il faut donc, initialiser la variable dans l'évènement "OnCreate" de la fiche en question.
Si cela paraît normal à quelqu'un, pourraît-il m'expliquer, s'il lui plaît ?
Merc d'avance.

[Fabrice ROUXEL 1]

C'est tout à fait normal!

tu as l'air de vouloir une variable globale qui se comporterait comme une variable locale.

Ce n'est pas le cas et dans aucun langage de programmation.

[od.dev]

ben...
pour moi, la portée d'une variable locale se limite à la proc ou la fonction dans laquelle elle est déclarée, et la portée d'une variable globale se limite à la fiche dans laquelle elle est déclarée.
Par conséquent, à partir du moment où la fiche dans laquelle elle a été déclarée est détruite, il me semblerait logique que cette variable ne soit pas conservée en mémoire...

[PadawanDuDelphi]

Salut,

Il faut donc, initialiser la variable dans l'évènement "OnCreate" de la fiche en question.

A priori, oui, puisqu'il faut bien initialiser ta variable au départ. Surtout que Delphi ne fixe pas de valeur initiale par défaut aux variables.

A+.

[Bruno Orsier]

Initialiser la variable dans le OnCreate donnera sans doute le comportement désiré. Mais attention tout de même: la mémoire allouée quand on déclare une variable globale dans une unité n'a absolument rien à voir avec la fiche qui est éventuellement déclarée dans cette unité. Et par conséquent il n'est pas "logique" de penser que la mémoire est libérée quand la fiche est libérée.

Bruno

[Gilbert Geyer]

pour moi, la portée d'une variable locale se limite à la proc ou la fonction dans laquelle elle est déclarée, et la portée d'une variable globale se limite à la fiche dans laquelle elle est déclarée.

Il ya du vrai et du faux là-dedans. En fait il y a une hiérachie dans les variables globales il y en a qui sont plus globales que d'autres en les classant depuis la plus locale jusqu'aux plus globales on a :

- var déclarée dans une routine = var la plus locale;

- var déclarée hors routines mais juste après "implementation et {$R *.DFM}" = var globale utilisable uniquement par toutes les routines situées après "implementation" on pourrait dire que c'est une variable globale à champ d'appel localisé,

- var déclarée dans la zone comprise entre "implementation" et var Form1 : tForm1 = var qui est non seulement glogale pour l'ensemble des routines de l'unité associée à cette Form1 mais également globale pour toutes les unités dont le uses cite cette unité.(Exemple : si je place ici dans une unité caisse-à-outils la constante cls =#13#10 et que cette unité est déclarée dans tous les uses du projet je peux ensuite utiliser cls n'importe où dans mon projet, et c'est kif-kif que cls désigne une constante, une variable, un type, un object, une fonction ou une procédure)

- ensuite dans la zone occupée par le type tForm1 : à l'exception d'une var déclarée dans la zone { Déclarations privées } tout est global pour l'ensemble des unités dont le uses cite l'unité de la Form1 ... et une var qui figure parmi les Déclarations privées est comme une variable locale d'usage réservé en principe à l'appel par les procédure déclarées dans le type tForm1.

- et enfin il y a toutes les variables de plus en plus globales qui sont déclarées dans les unités qui s'affichent automatiquement (ou qu'on ajoute manuellement) dans les uses (à commencer par toutes les var spécifiques à Delphi).

à partir du moment où la fiche dans laquelle elle [la var] a été déclarée est détruite, il me semblerait logique que cette variable ne soit pas conservée en mémoire

La destruction d'une fiche ne provoque que la destruction : - des propriétés (du style top,left, etc de cette fiche et de ses composants), - et des var déclarées à l'intérieur du type tForm1 et qui concernent cette même fiche ... et comme la destruction d'une fiche ne signifie pas destruction de l'unité qui gère cette fiche toutes les autres variables globales sont conservées en mémoire y compris celles qu'on a éventuellement remis à zéro dans la routine qui comporte l'instruction de destruction de la fiche.

[od.dev]

Donc si j'ai bien compris :
1) Les variables globales déclarées dans une fiche n'existent et ne sont, éventuellement, initialisées qu'à la création de la form définie par cette fiche.
2) Elle ne disparaissent pas avec la destruction de la form, et ne sont pas réinitialisées lors d'une nouvelle construction dynamique de cette form.

Force est de constater que :

//
private

public

end;

var
Form1: TForm1;
NumComp: Word = 0;

implementation
//

La variable NumComp est initialisée à 0 lors de la 1ère création dynamique de Form1.
Elle est incrémentée lors de l'utilisation de Form1, et lors du Release de celle-ci, NumComp vaut 1.
Lors de la 2e construction dynamique de Form1, NumComp vaut toujours 1.
Il me faut donc inialiser NumComp à 0 dans FormCreate.
Je ne trouve pas cela très logique, je pensais que tout était libéré après release.

J'en prends acte et je vous remercie beaucoup pour vos explications.

[Bruno Orsier]

Dans l'exemple que vous donnez il n'y a aucune relation entre la création de Form1 et de NumComp: la premiere création de Form1 n'a aucune influence sur NumComp (sauf si vous manipulez NumComp dans le OnCreate de la fiche).

NumComp va être initialisée à 0 lors de l'initialisation de l'unité (je pense), et restera à 0 tant que vous ne la manipulez pas depuis une méthode de la fiche, ou depuis une autre unité d'ailleurs vu que NumComp est déclarée dans l'interface de l'unité.

Bruno