Discussion :

[Jinx_]

Re-bonjour,

J'ai 2 form. J'appelle la seconde par un bouton sur la premiere mais j'ai besoin d'avoir des variables visible depuis de la form1 ET depuis la form2 (ou de l'unit1 et de l'unit 2) ? Comment faire ?

En Visual Basic il y a des module "global" qui permettent de déclarer des variable globale au "program" et visible depuis toute les feuilles. Existe t-il cette notion en Delphi ?

Jinx

[ero-sennin]

Re,

Pour faire ce que tu demandes, tu as 2 possibilités :

Dans la section var de la Form1 tu déclares tout ce qui doit être globale :

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
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Forms,
  Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

var
  Form1: TForm1;
  Toto:String;

implementation

Tu prends soin d'inclure l'unit1 (Form1) dans la Form2 ... Fichier, Utilisé l'unité ...
Ensuite, à partir de Form2, pour modifier la variable TOTO, il suffit de l'utiliser normalement...

L'autre solution consiste à mettre dans la partie Public de Form1 ta variable :

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
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Forms,
  Dialogs;

type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
    Toto:String;
  end;

var
  Form1: TForm1;

implementation

et du coup, dans form2 (toujours en incluant les unités auparavant), on fait ceci (par exemple) :

Code :

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

Form1.Toto:='UnTruc';

J'espère que ma réponse est assez claire.
A+

[Jinx_]

OK Merci de ton aide ero-sennin.

Je viens juste d'ouvrir mon projet en clickant sur le fichier .bdsproj et l'EDI ouvre un fichier qui s'emblet-il est le corps du programe principal.

J'ai le code suivant:

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
 
program Project1;
 
uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas' {frmGraph};
 
{$R *.res}
 
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TfrmGraph, frmGraph);
  Application.Run;
end.

Est-ce que, si j'ajoute un section "VAR" dans le code qui précédè, j'obtiens bien le résultat que je cherche (c'est a dire obtenir des variables visible globalement) ?

Jinx

[ero-sennin]

Aie !

Je n'ai pas BDS comme IDE mais Delphi7. Lorsque j'ouvre mon projet, je fais double clic sur project1.dpr ... Je ne peux t'en dire plus Désolé

[Jinx_]

J'ai essayé sur Turbo Belphi de Borland mais ca ne marche pas. Il decouvre une erreur de syntaxe lorsque j'ecris VAR. Curieux.

Mais merci de ton aide.

(je teste demain ton 'truc' puis je clos le sujet par 'résolut')

Jinx

[Rayek]

Le mieux pour des variables globales et d'utiliser une unité dédiée à cela.

Exemple

UGlobal.pas

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
 
Unit UGlobal
 
interface
 
type
  TMonTypeGlobal = record
  Val1 : String;
  Val2 : Integer;
end;
 
const 
  MaConstanteGlobale = 10;
 
var
  MaVarGlobal : String;
 
 
implementation
 
end.

Après il ne te reste plus qu'à rajouter cette unité dans les uses de tes unités qui en auront besoin.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
unit Unit1;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Forms,
  Dialogs, 
 
  uGlobal;
 
// ...

[trident_job]

Le petit plus, pour assurer un couplage minimal entre les composants de ton appli (et donc un design efficace), c'est de ne pas utiliser de variables globales.
Mieux vaut passer par une / des fonctions déclarées publiques dans ta form, qui te retournerons les valeurs dont tu as besoin, voire une seule qui te retourne un type ou une classe complète.

exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
type
  TWizardProjectForm = class(TForm)
  [...]
  public
    { Public declarations }
    function GetRootDirectory: TFilename;
  end;
 
function TWizardProjectForm.GetRootDirectory: TFilename;
begin
  { receiving code expects path delimiter }
  Result := FRoot + PathDelim;
end;

du coté de la Form qui utilise ces données :

Code :

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

1
2
 
MyFolder := WizardProjectForm.GetRootDirectory;

Si cela peut aider

[Laurent Dardenne]

Le petit plus, pour assurer un couplage minimal entre les composants de ton appli (et donc un design efficace), c'est de ne pas utiliser de variables globales.

Voir aussi le pattern Singleton :
http://www.castle-cadenza.demon.co.uk/single.htm

[Rayek]

Le petit plus, pour assurer un couplage minimal entre les composants de ton appli (et donc un design efficace), c'est de ne pas utiliser de variables globales.

Je ne suis pas trop d'accord sur le fait qu'il ne faille pas utiliser de variable globale.

Il m'arrive souvent d'utiliser une variable globale indiquant le chemin de mon application que j'initialise au démarrage de mon application afin de m'eviter de retapper à chaque fois la même ligne de commande.

Ex :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
unit uDefs
 
interface
 
var
  GAPPPATH ,
  GAPPPLOG : String;
 
implementation
end.

dans le onCreate de ma fiche principale

Code :

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

1
2
3
4
5
6
 
GAPPPATH := ExtractFilePath(Application.exeName);
GAPPLOG := GAPPPATH + 'logs\';
 
if not directoryExist(GAPPLOG) then
  forcedirectory(GAPPLOG);

Si vous avez une solution sans variable globale, je suis prenneur

[Gilbert Geyer]

Bonjour,

Je soutiens le point de vue de Rayek suggérant l'utilisation d'une Unit UGlobal pour y loger les variables globales et j'irais même plus loin car dans ce genre d'unité appellable depuis toutes les autres j'y ajoute pour ma part toute une série de fonctions utilitaires d'usage courant et d'intérêt global qui m'évitent de retapper trente-six fois les mêmes trucs à chaque besoin et du coup UGlobal se transforme en une sorte de UCaisseAOutils.
En plus cette UCaisseAOutils passe d'une appli à la suivante ce qui évite encore d'avoir à retapper et en cas d'ajouts ou de modifications elle change de nom ou de numéro.
Cela évite également d'avoir à recréer des trucs qu'on a déjà créés-testés-peaufinés, et ou bout d'un momment cela peut devenir une collection de perles.

A+

[trident_job]

Je ne suis pas trop d'accord sur le fait qu'il ne faille pas utiliser de variable globale.

Je n'ai pas dit jamais, seulement qu'il faut éviter !

Juste une précision, mais je comprends que chacun a son point de vue :
Une variable globale met à disposition de tout module un accès en lecture / ecriture à la donnée, ainsi qu'un couplage fort. Si la variable change de type ou si un traitement est associé, ca devient le chantier.

Passer par un accesseur, donc une fonction ou mieux une propriété, permet de se dégager de ces contraintes, et d'affiner le couplage entre module, de garantir l'indépendance qui conduit à une maintenance facilité du design.

POur aller plus loin : lors d'une modélisation poussée, les données globales n'ont généralement pas leur place. Chaque donnée n'appartient qu'à un module qui n'existe que pour elle (le Fondement de base de la POO c'est bien le couple donnée / traitement non ?).

Le graphe UML d'une unité qui ne contient que des données globales sera une véritable araignée ==> des liens partout entre chaque module et cette unité "GlobalVar".

Pour finir, je ne cherche pas à mettre tout le monde d'accord, j'imagine que chacun à son avis en fonction de son experience et de ses exigences.

bonne nuit !

[Paul TOTH]

OK Merci de ton aide ero-sennin.

Je viens juste d'ouvrir mon projet en clickant sur le fichier .bdsproj et l'EDI ouvre un fichier qui s'emblet-il est le corps du programe principal.

J'ai le code suivant:

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
 
program Project1;
 
uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1},
  Unit2 in 'Unit2.pas' {frmGraph};
 
{$R *.res}
 
begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TfrmGraph, frmGraph);
  Application.Run;
end.

Est-ce que, si j'ajoute un section "VAR" dans le code qui précédè, j'obtiens bien le résultat que je cherche (c'est a dire obtenir des variables visible globalement) ?

Jinx

il est possible de déclarer des variables dans le DPR, mais elles ne seront visible dans aucune unité du projet.

il faut bien avoir à l'esprit que sous Delphi les dépendances sont arborescentes.

le DPR utilise des Unités qui n'ont pas connaissance du DPR
chaque unité utilise d'autres unités qui n'ont pas connaissance de celles-ci.

bon en fait il existe une exception quand deux unités se références mutuellements. Mais dans ce cas, l'une doit référencer l'autre dans sa partie Interface et l'autre dans sa partie Implementation sous peine de référence circulaire.

Et personnellement je n'ai rien contre les variables globales, Delphi en fait d'ailleurs largement usage avec une variable pour chaque fiche (Form1, Form2...) ni contre les fonctions et procédures qui ne sont pas des méthodes de classe d'ailleurs