Discussion :

[patdu26]

Bonjour à tous,

il y a quelques temps, j'avais une difficulté pour utiliser une variable dans plusieurs unités.
Grâce à l'aide sur le site, j'ai créé une unité "partager", qui contient cette variable.
Les unités utilisant cette variable, font simplement apparaitre l'unité "partager" dans leurs clauses "uses".

En relisant la doc embarcadero, je vois que tout ce qui est déclaré dans la partie "interface", avant la partie "implémentation", (les variables notamment), serait visible de partout, dans toutes les autres unités "clientes", ce qui pourtant ne peut être interpréter ainsi puisque ce n'est pas possible spontanément, l'unité appelée ne voyant pas l'existence d'une variable créée dans la partie "interface" de l'unité principale.






Comment faut-il comprendre ce passage? Quelle erreur d'interprétation je fais, en raisonnant ainsi?

Merci à tous...

[Bernard B]

Bonjour,

Perso voilà comment j'utilise les unités pour par exemple avoir des variables communes à toutes les unités de mon application :

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
24
25
26
27
28
29
 
unit MonUnitDeVariables;
 
interface
Uses ;//éventuels nécessaires dans Cette unité
 
type // on peut déclarer des nouveau types de variables ou d'objets....
 
private
//on declare ici les variables qui sont utilisées en interne par cette unité
 
public
 
// on déclare ici les variables, les procédures et les fonctions qui
// seront vues et modifiables par toutes les unités ayant mis  'MonUnitDeVariables' dans leur uses
 
implementation
Uses ; //pour mettre les unités nécessaires en interne de cette unité
 
// le code des fonctions et procédures
 
initialization
//pour mettre tout ce qui doit se faire juste après la création de cette unité
// bon endroit pour initialiser les variables, créer les TStringList....
 
finalization
//pour libérer tout ce qui a été créé (objet, TStringList...) par cette unité avant qu'elle ne soit détruite
 
end.

[Andnotor]

... qui souhaitent utiliser les éléments de cette unité

Ce souhait est exprimé par l'insertion de l'unité dans une des clauses uses

[Galet]

Salut,
Chaque unité peut accéder a ses propres variables ainsi qu'aux variables déclarées dans les zones Interfaces des unités attachées par Uses.
Il est donc possible de créer des données accessibles à toutes les unités d'un projet en les déclarant dans l'interface d'une unité qui sera ensuite attachées dans toutes les autres unités.

Les variables déclarées dans la zone implémentation ne sont accessibles que dans cette même zone de la même unité.
Les variables déclarées dans une procédure ou fonction ne sont accessibles qu'à cette même procédure ou fonction.


Attention, pour faciliter la maintenance des applications, il est préférable de limiter au mieux la portée des variables.
Cette méthode permet de localiser les variables au même titre que les procédures et fonctions, mais aussi de limiter le nombre de variables.

Cordialement,

[Paul TOTH]

la structure d'un programme Pascal (ou Delphi) est fort simple.

tout part du source principale (le .DPR) qui déclare le point d'entrée de l'application

Code :

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

1
2
3
4
5
6
 
program Projet1;
 
begin
// le point d'entrée de l'application
end.

afin de ne pas mettre tout le code dans le source principale, ou pour réutiliser des portions de code dans différents projets, on peut placer une portion du code dans des Unités

l'unité possède deux parties, une partie Interface et une Implementation

Code :

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

1
2
3
4
5
6
7
8
 
unit Unit1;
 
interface
 
implementation
 
end.

la partie Interface est déclarative, on ne peut y mettre aucun code, mais on doit y mettre toutes les déclarations auxquelles les programmes qui utilisent cette unité ont accès

la partie Implementation correspond à ce dont l'unité à besoin pour répondre à son interface

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
 
unit Unit1;
 
interface
 
procedure DireBonjour; // déclaration
 
implementation
 
procedure DireBonjour; // le faire
begin
  WriteLn('Bonjour');
end;
 
end.

maintenant pour utiliser la fonction DireBonjour, dans n'importe quel partir du projet (source principal ou unité) il suffit de faire référence explicitement à Unit1 pour pouvoir appeler la fonction

Code :

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

1
2
3
4
5
6
7
8
9
10
 
program Projet1;
 
uses
  Unit1; // à partir de cette ligne, "DireBonjour" est connu et peut être utilisé
 
begin
// le point d'entrée de l'application
  DireBonjour; 
end.

Si l'unité déclare d'autres fonctions dans la partie Implementation sans en faire mention dans la partie Interface, elles ne seront pas utilisables en dehors de Unit1 elle-même, ce sont des fonctions internes dont elle a besoin mais qui ne sont pas utilisables dans d'autres partie du code.

la même règle s'applique pour les variables, constantes et types déclarés dans Unit1, ils sont visibles s'ils sont dans la partie Interface, et "privés" s'ils sont dans la partie Implementation.

Ensuite on peut avoir un problème de référence circulaire.

[patdu26]

Merci à tous pour votre réactivité et vos pistes de travail.

En fait, au départ, je souhaite "saucissonner" mon programme en cours, car les lignes s'accumulant, il est très difficile de s'y retrouver vraiment.
Je désire donc agir de la manière suivante :
- un corps "principal", avec tout le déroulement et les appels aux procédures.
- des unités .pas pour rédiger, relire et modifier aisément ces procédures.

En fait, j'ai rapidement vu qu'il est difficile d'appeler des "morceaux de prgs" sous forme de fiches, avec des variables communes, sans avoir le problème de non déclaration ou appel circulaire.

j'ai fait un petit essai qui à l'air de fonctionner :

le prg principal fait apparaitre des clauses "uses" de chaque fiche dans la partie "implémentation".
La variable "message", déclarée dans la partie "interface" peut être utilisée par les différentes fiches.

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
unit Unit11;
 
interface
 
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;
 
 
 
 
type
  TForm11 = class(TForm)
    procedure FormActivate(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;
 
var
  Form11: TForm11;
  message : string;
 
implementation
   uses unit12, unit13;
 
{$R *.dfm}
 
procedure TForm11.FormActivate(Sender: TObject);
begin
       message := (' je suis dans l''unité 11');
   showmessage (message);
   phrase12 ;
    showmessage (message);
   phrase13 ;
    showmessage (message);
end;
 
end.

Chaque fiche fait apparaitre le prg principal dans la partie "implémentation" et indique l'en-tête de la procédure traitée dans la partie "interface" et utilise la variable partagée "message".

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
unit Unit12;
 
interface
 
   procedure  phrase12 () ;
 
implementation
 
      uses unit11;
 
     procedure phrase12 ();
     begin
      message := (' je suis entré dans l''unité 12');
     end;
 
end.

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
unit Unit13;
 
interface
 
procedure phrase13 ();
 
implementation
 
     uses unit11;
 
     procedure phrase13 ();
     begin
      message := (' je suis entré dans l''unité 13');
     end;
 
end.

Cela fonctionne pour cet exemple simple, mais ce principe peut-il être appliqué pour un programme des plusieurs centaines de lignes?
Le principe de "saucissonnage" est -il correct? adapté? ou dois-je faire autrement pour être efficient? Merci à tous!

[tourlourou]

Bonjour,
Dans ton exemple, les fiches 12 et 13 n'ont pas besoin d'utiliser l'unité 11.

[Paul TOTH]

Bonjour,
Dans ton exemple, les fiches 12 et 13 n'ont pas besoin d'utiliser l'unité 11.

si pour accéder à la variable globale message

ceci dit, si dans le principe ça fonctionne je ne recommande pas l'usage d'une variable globale pour passer des paramètres

il y a des tas de façon plus sophistiquées de le faire...mais surtout plus polyvalentes....vu l'exemple je ne vais pas développer...mais ça pourrait être un objet TLog, une méthode de Form1, une fonction callback...

[tourlourou]

Oui, pardon !
J'ai lu trop vite ShowMessage à la place...

[Galet]

Si tu souhaites réutiliser certaines fonctionnalités dans d'autres projets, il est préférable de conserver le regroupement des données avec les procédures qui les gèrent.
On retrouve le principe même de la programmation Objet.
Les variables globales te poseront beaucoup de problème en cas de réutilisation d'une de tes unités....

Le danger de créer une unité spécifique pour héberger les données et outils nécessaires à tout le projet est de la voir se transformer en fourre-tout ..
Cordialement,

[patdu26]

merci à tous pour vos contributions!

Pour éviter le coté "fourre-tout" d'une unité partagée, et permettre une réutilisation plus facile des fiches, le principe ci-dessous est-il correct?

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
24
25
26
27
28
29
30
31
32
33
34
35
unit Unit11;
 
interface
 
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, calcul;
 
type
  TForm11 = class(TForm)
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;
 
var
  Form11: TForm11;
 
  nb1, nb2 : integer;
 
 
 
implementation
 
 
{$R *.dfm}
 
 begin
    nb1 := 10;
    nb2 := 5;
    produit (nb1,nb2);
    showmessage ('le resultat est : ' + resultat.ToString);
 
end.

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
unit calcul;
 
interface
 
 
    var resultat : integer;
  procedure produit (i,j : integer) ;
 
implementation
 
   procedure produit ;
   begin
     resultat := i*j;
   end;
 
end.

L'unité secondaire "calcul", possède sa procédure et sa variable déclarée, accessibles à tous, car dans la partie interface.

Le projet principal ajoute "calcul" dans ses "uses" et ainsi, peut appeler la procédure "produit" et accéder à la variable "résultat".

Le passage des paramètres se fait par l'appel de la procédure, qui les traite en variables locales "i" et "j", mettant à disposition "resultat" pour toutes les fiches faisant apparaitre le "uses calcul".

Cela est-il correct? Ce principe est-il applicable pour plusieurs procédures plus compliquées?

[Paul TOTH]

merci à tous pour vos contributions!

Pour éviter le coté "fourre-tout" d'une unité partagée, et permettre une réutilisation plus facile des fiches, le principe ci-dessous est-il correct?

Non

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
unit Unit11;
 
interface
 
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, calcul;
 
type
  TForm11 = class(TForm)
  private
    { Déclarations privées }
   Button1: TButton; // ajouté automatiquement si on place un bouton sur la fiche
  public
    { Déclarations publiques }
    procedure Button1Click(Sender: TObject); // ajouté automatiquement quand on double clique sur le bouton
  end;
 
var
  Form11: TForm11;
 
//  nb1, nb2 : integer; rien à faire ici
 
 
 
implementation
 
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
 begin
//    nb1 := 10;
//    nb2 := 5;
//    produit (nb1,nb2);
//    showmessage ('le resultat est : ' + resultat.ToString);
  ShowMessage('le result est : ' + produit(10, 5).ToString);
end;
 
// pourquoi donc mettre un code ici ?
end.

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
unit calcul;
 
interface
 
 
//    var resultat : integer;
  function produit (i,j : integer) : Integer;
 
implementation
 
   function produit(i, j: Integer): Integer ; // le rappel des paramètres n'est pas obligatoire mais j'aime bien le faire
   begin
     Result := i*j; // Result est la variable résultat automatiquement déclarée
   end;
 
end.

[popo]

Si ton besoin est faire des calculs, il n'est pas nécessaire d'utiliser des variables globales.
Il suffit de demander les éléments nécessaires à un calcul en paramètre et de retourner le résultat.

Pour simplifier la consommation tu peux créer une classe de calcul qui fournit plein de routine de calcul, voire stocker des informations dans des membres privés de cette classe.
Pour le consommateur, c'est plus simple car tout est réuni au même endroit.

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
24
25
26
27
28
class function CalculSurTriangle.IsTriangleRectangle(const a, b, c: Extended): Boolean;
var LePlusLong, x, y : Extended;
    x2, y2, LePlusLong2 : Extended;
begin
  LePlusLong := a;
  x := b;
  y := c;
 
  if (b > LePlusLong) then
  begin
    x := a;
    y := c;
    LePlusLong := b;
  end;
 
  if (c > LePlusLong) then
  begin
    x := a;
    y := b;
    LePlusLong := c;
  end;
 
  x2 := x * x;
  y2 := y * y;
  LePlusLong2 := LePlusLong * LePlusLong;
 
  Result := ((x2 + y2) = LePlusLong2);
end;

ou bien

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
24
25
26
27
28
29
30
31
32
33
34
35
constructor CalculSurTriangle.Create(const a, b, c: Extended);
begin
    FA := a;
    FB := b;
    FC := c;
end;
 
function CalculSurTriangle.IsTriangleRectangle : Boolean;
var LePlusLong, x, y : Extended;
    x2, y2, LePlusLong2 : Extended;
begin
  LePlusLong := FA;
  x := FB;
  y := FC;
 
  if (FB > LePlusLong) then
  begin
    x := FA;
    y := FC;
    LePlusLong := FB;
  end;
 
  if (FC > LePlusLong) then
  begin
    x := FA;
    y := FB;
    LePlusLong := FC;
  end;
 
  x2 := x * x;
  y2 := y * y;
  LePlusLong2 := LePlusLong * LePlusLong;
 
  Result := ((x2 + y2) = LePlusLong2);
end;

[patdu26]

bonjour à tous,

je comprends l'intérêt de l’utilisation de "function", qui permet de sous-traiter un calcul et rapatrier le résultat quand on reprend la main.
Mais est-il possible de rapatrier plusieurs résultats par cette démarche, ou uniquement un seul, nommé "result".

Dans mon idée, je souhaite mettre en page des images de dimensions fixes sur mon écran, en effectuant une mise en page en fonction de la définition de mon écran, du nb d'images, du nb de colonnes et du nb de lignes choisies.

Ma fiche sous-traitante, reçoit donc la hauteur, la largeur de la surface client, le nombre, la hauteur et la largeur d'une image, le nombre de ligne et de colonnes désirées.

Avec tout ça, je dois récupérer l'espacement horizontal et l'espacement vertical de deux images voisines, ainsi que les coordonnées x et y calculées pour chacune.

Au retour ces données doivent être dispos pour le programme principal qui assure l'affichage des images dans sa Form.

Dans cette optique, quel est la meilleurs stratégie?...

[Jipété]

Mais est-il possible de rapatrier plusieurs résultats par cette démarche, ou uniquement un seul, nommé "result".

Oui.
Exemple ici, déjà Paul, il y a 13 ans...

[ALWEBER]

Tu crée un type record avec deux éléments puis ta fonction retourne ce type
Ex.

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
 
Type t1 = record
  larg, haut : integer
end ;
 
function f1 (i1 : integer) : t1 ;
begin
  result.larg := i1*4
  result.haut := i1*3
 
end
 
var
  v1 : t1 ;
begin
  v1 := f1(200) ;
end ;

[tourlourou]

Ma fiche sous-traitante, reçoit donc la hauteur, la largeur de la surface client, le nombre, la hauteur et la largeur d'une image, le nombre de ligne et de colonnes désirées.

Avec tout ça, je dois récupérer l'espacement horizontal et l'espacement vertical de deux images voisines, ainsi que les coordonnées x et y calculées pour chacune.

Code :

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

1
2
3
4
5
6
7
type 
 TContraintesPlacement = record // pour alléger le passage de paramètres, mais c'est un choix ; ce n'est pas "mieux"
  ClientHeight, ClientWidth, ImageNumber, ImageHeight, ImageWidth, ColNumber, RowNumber: integer;
 end;
 
 
function CalculeEmplacements(const aContraintesPlacement: TContraintesPlacement; var aHSpace, aVSpace: integer; var aEmplacements: array of TPoint): Boolean; // retourne True et les résultats en var si calculs OK ; False sinon

[ALWEBER]

Code :

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

1
2
3
4
5
6
7
type 
 TContraintesPlacement = record // pour alléger le passage de paramètres, mais c'est un choix ; ce n'est pas "mieux"
  ClientHeight, ClientWidth, ImageNumber, ImageHeight, ImageWidth, ColNumber, RowNumber: integer;
 end;
 
 
function CalculeEmplacements(const aContraintesPlacement: TContraintesPlacement; var aHSpace, aVSpace: integer; var aEmplacements: array of TPoint): Boolean; // retourne True et les résultats en var si calculs OK ; False sinon

Un peu tordu pour répondre à un débutant

[patdu26]

Merci aux intervenants du jour, qui m'ont guidé vers les fonctions à plusieurs paramètres et plusieurs résultats

J'ai fait quelques tests en suivant vos exemples, et ça fonctionne très bien.
J'envoie plusieurs paramètres, et grâce au type créé avec "record", je récupère bien les résultats multiples voulus.

Je vais tenter d'appliquer cela à des constructions plus complexes.

Merci encore!

[tourlourou]

@Alain : tu as un peu raison !

Mais il me semble que ce type de solution est couramment utilisé dans les sources de Delphi/Lazarus ou dans les API. Après, je me suis peut-être emballé...