Discussion :

[SkyWalker]

Débutant en delphi, je but sur des problème de portée.

Je souhaite déclarer une instance d'une classe au niveau de l'application et pouvoir utiliser cette même instance dans toutes les autres unités du programme

Quelle est la bonne méthode pour y arriver

D'avance Merci

[Clorish]

Il suffit d'appliquer la methode des Forms :

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
 
Unit MonUnit;
 
Interface
 
Type
  TMaClasse = Class
  [...]
  End;
 
Var MaClasse : TMaClasse;
 
Interface
 
[...]
 
Initialization
  If not Assigned(MaClasse) Then MaClasse := TMaClasse.Create;
 
Finalization
  If Assigend(MaClasse) Then MaClasse.Free;
 
End.

Toutes variable declarée dasn la partie interface d'une unitee est accessible a toutes unitee la declarant.

Les section Initialization/Finalization sont respectivement appelées quand l'unitee est chargée/Dechargée de la memoire.
L'endroit ideal pour coder la creation/Liberation de ces objets, A moins qu'ils ne soient liés a d'autres, dans ce cas, il faut penser a tester si l'obejt est bien cree avant de l'utiliser et bien sur penser a le creer le temps voulu

[SkyWalker]

Merci pour cette réponse rapide que j'essaierais de mettre en pratique ce soir.

En fait si je comprend bien cet exemple, c'est l'unité qui se charge de déclaré (instancier) son objet

Ensuite, toutes les autres unités qui utiliseront MonUnit (en la référençant dans le uses), pourront accéder à l'objet MaClasse sans avoir besoin de créer une autre instance de celui-ci. Le même objet MaClasse est alors accessible à toutes les unités le référançant.

La section Finalization est exécutée par delphi quand plus aucune unités ne fait référence à MonUnit.

C'est bien ça ?

[Clorish]

En fait c'ets plus simpel que ca.
La section Interface est la partie publique de l'unitee.
tout ce qui y est declaré est accessible depuis une autre unitee.

On a pour habitude de l'utiliser pour declarer des classes et des constantes accessibles dans une autre unitee en la referencant dans les clauses Uses.

On peut aussi declarer des variables qui seront de fait utilisable dans d'autres unitee.

Quand a leur usage, il ne pourra se faire qu'apres instenciation de la variable.
La variable est accessible mais pas pour autant instanciee.

Donc normalement on la cree depuis n'importe quelle procedure de l'application (FormCreate ?) ...

Mais il existe un systeme assez peu connu : celui du chargement et du dechargement des unitees, ce qui permet de creer l'instance des le chargement de l'unitee donc avant tout appel au code de cette derniere.

Pour repondre a ta derniere question, une unitee est dechargee en fin d'application, quand le programme se termine.
Il est a noter que liberer l'objet a ce moment n'est pas utile car juste apres, l'application rends l'espace memoire que windows lui a aloué, donc libere l'espace memoire de la classe en question. Fuite memoire de quelques fractions de secondes

Une derniere chose, on peut utiliser une unitee comme une classe.
D'ailleur Delphi permet ceci :

Code :

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

1
2
3
4
5
 
Uses MonUnit;
Begin
Monunit.MaClasse := TMaClasse.Create;
End;

[Laurent Dardenne]

Je me permets une petite remarque :

Mais il existe un systeme assez peu connu : celui du
chargement et du dechargement des unitees,

Les termes chargement/déchargement laissent supposer qu'il y a une opération disque quelque part.
Autant reprendre ceux de Delphi :
Initialization : initialisation, c'est à dire débuter qq chose, si c'est demandé.
Finalization "mener à bonne fin" c'est à dire dans notre cas s'assurer d'une fin correcte, si c'est demandé.
Il y a aussi une notion sous jacente de chaînage ordonné, ordre pouvant qq fois avoir son importance.

Une derniere chose, on peut utiliser une unité comme une classe.

Moi je lis unité=classe
Tu parles de la possibilité de préfixer un nom de classe par un nom d'unité pour lever toute ambiguïté quant à sa localisation ou d'autres choses ?

[Clorish]

Les termes chargement/déchargement laissent supposer qu'il y a une opération disque quelque part.

Pas forcement .. en l'occurence c'ets un chargement en memoire
D'ailleur c'est aussi plus ou moins directement un chargement depuis le disque vu que les unitees ou plutot le code relatifs aux fonctionnalitées de cette unitee est chargee depuis l'executeble ... a priori situé sur le Disque

Le terme d'initialisation est vrai, mais c'est une fonctionnalité lié au chargement.
C'est lors du chargement en memoire que l'unitee s'initialise, donc fait appel a ce code
Pour moi, la transitivité fait que c'ets au chargement que l'on execute ce code
D'autant que l'initialization n'a pas lieu a d'autres moments ....

Moi je lis unité=classe
Tu parles de la possibilité de préfixer un nom de classe par un nom d'unité pour lever toute ambiguïté quant à sa localisation ou d'autres choses ?

Oui la c'est un ecart de langage
Je voyais surtout l'outils de completion de code qui finalement manipule une unitee un peu comme une classe ne contenant que des methodes de classes.

A noter que l'on retrouve un peu de genre de chose en Java. Une classe peut exporter des constantes, des methodes, des methodes de classes, des variables, .... seul les types ne peuvent pas etre defini au sein d'une classe.