Utilisation du programme

L'utilisateur saisi un prénom, un nom et un opérateur, puis clique sur le bouton Mail, le programme affiche le mail de cette personne chez cet opérateur dans la zone de texte étiquetée Mail:

Déclaration de procédure

Voici un premier extrait du code du programme (nous avons numéroté les lignes afin de pouvoir les commenter):

01: var
02:  Form1: TForm1;
03:  mail : string;

04: implementation

05: procedure FormerMail (p,n,o : string);
06: begin
07:  mail := p+'.'+n+'@'+o+'.fr';
08: end;

09: procedure TForm1.BT_MailClick(Sender: TObject);
10: var prenom, nom, operateur : string;
11: begin
12:   Lire (prenom, ZT_Prenom);
13:   Lire (nom, ZT_Nom);
14:   Lire (operateur, ZT_Operateur);
15:   FormerMail(prenom,nom,operateur);
16:   Afficher (mail, ZT_Mail); 
17: end; 

Les lignes 5 à 8 constituent la déclaration d'une procédure non évènementielle nommée FormerMail.

Les lignes 9 à 17 représentent la déclaration une procédure évènementielle.

Nous expliquerons quelles sont les différences entre ces deux types de procédures un peu plus loin.

Détaillons à présent la déclaration de la procédure FormerMail:

05: procedure FormerMail (p,n,o : string);
06: begin
07:  mail := p+'.'+n+'@'+o+'.fr';
08: end;

La ligne 5 est l'entête de la procédure. L'entête commence par le mot clé procedure, suivi par le nom de la procédure (ici FormerMail), puis des paramètres (appelés également paramètres formels) de la procédure. Dans notre cas, les paramètres sont donc p, n et o.

Les paramètres figurent entre parenthèses. Ce sont en quelque sorte des variables locales associées à la procédure. Nous verrons à quoi ils servent un peu plus loin. Le type de chaque paramètre doit être précisé. Dans cet exemple, les trois paramètres p, n et o sont tous du type String.

La partie entre begin (ligne 6) et end (ligne 8) est appelée le corps de la procédure.

En ce qui concerne la déclaration, la seule différence entre une procédure évènementielle et une procédure non évènementielle est le fait que l'entête d'une procédure non évènementielle est automatiquement générée. En particulier, le nom de la procédure est généré à partir du nom du composant concerné et du nom de l'évènement.

Pour coder une procédure évènementielle, le développeur doit donc simplement complèter le corps de la procédure. Par contre, le code d'une procédure non-évènementielle est entièrement écrit par le développeur.

Exécution de procédures

Vous savez déjà que le code d'une procédure évènementielle s'éxécute lorsque l'évènement associé à cette procédure à lieu. Par exemple, la procédure BT_MailClick sera exécutée chaque fois que utilisateur cliquera sur le bouton BT_Mail.

Pour une procédure non évènementielle, les choses fonctionnent de manière différente:

Dans notre exemple cette instruction figure en ligne 15:

09: procedure TForm1.BT_MailClick(Sender: TObject);
10: var prenom, nom, operateur : string;
11: begin
12:   Lire (prenom, ZT_Prenom);
13:   Lire (nom, ZT_Nom);
14:   Lire (operateur, ZT_Operateur);
15:   FormerMail(prenom,nom,operateur);
16:   Afficher (mail, ZT_Mail); 
17: end; 

Dans notre exemple, les valeurs les paramètres effectifs sont donc prenom, nom et opérateur.

Supposons par exemple que l'utilisateur entre les valeurs 'Robert' pour le prénom, 'Johnson' pour le nom et 'free' pour l'opérateur, puis clique sur le bouton Mail. Il se passera alors la chose suivante (figure):

1. La procédure évènementielle BT_MailClick commence à s'exécuter. De la mémoire est allouée pour les variables locales prenom,nom et operateur.
2. les instructions de lecture contenues dans cette procédure sont ensuite exécutées. Les variables nom, prenom et operateur contiennent donc à présent les valeurs 'Robert', 'Johnson' et 'free' respectivement.
3. le processeur rencontre à présent l'instruction d'appel de la procédure FormerMail. A ce moment, il interrompt provisoirement l'exécution de la procédure appelante (BT_MailClick dans notre cas) pour s'occuper d'exécuter cet appel de procédure.
4. Le début de l'exécution de l'appel d'une procédure est le passage des paramètres: de la mémoire est allouée aux paramètres formels (p, n et o dans notre cas), puis les valeurs des paramètres effectifs leurs sont affectées. Dans notre cas, les valeurs des paramètres formels prenom, nom et opérateur, soit 'Robert', 'Johnson' et 'free' respectivement, sont affectés aux paramètres formels p, n et o.
5. les instructions de la procédure sont ensuite exécutées avec ces valeurs de paramètres. Dans notre cas, il s'agit de l'instruction mail := p+'.'+n+'@'+o+'.fr';. Après l'exécution de cette instruction, la variable globale mail contiendra donc 'Robert.Johnson@free.fr'.
6. Après avoir exécuté le code de la procédure, la mémoire allouée aux paramètres est libérée et le processeur reprend l'exécution de la procédure appelante (FormerMail dans notre cas) à l'instruction qui suivait l'appel. Dans notre cas, il s'agit de l'instruction Afficher (mail, ZT_Mail);. La valeur de la variable Mail est donc affichée dans la zone de texte.
7. Nous arrivons à présent à la fin de l'exécution de la procédure évènementielle BT_MailClick. La place mémoire allouée aux variables locales prenom,nom et operateur est libérée. Puis le programme retourne à un état d'attente d'un évènement.

Une manière de comprendre l'appel d'une procédure est d'imaginer qu'à la place de l'appel de procédure figurent les instructions de la procédure dans lesquelles les paramètres formels sont remplacé par les paramètres effectifs (figure).