---

Plan du chapitre:
 

1. Programmes événementiels avec Delphi

1.1 Pointeur de méthode
1.2 Affecter un pointeur de méthode
1.3 Un événement est un pointeur de méthode
1.4 Quel est le code engendré

2. Exercice-récapitulatif

Un pointeur de méthode est  une paire de pointeurs (adresses mémoire), le premier contient l'adresse d'une méthode et le second une référence à l'objet auquel appartient la méthode.

Pour pointer la méthode d'une instance d'objet en Delphi,  nous devons déclarer un nouveau  type auquel nous ajoutons à la fin le qualificateur of object .

  ptrMethode1 = procedure of object;
  ptrMethode2 = procedure (x : real) of object;

  Proc1 : ptrMethode1;  // pointeur vers une méthode sans paramètre
  Proc2 : ptrMethode2; // pointeur vers une méthode à un  paramètre real

procedure P1; begin end;	procedure P3 (x:char); begin end;
procedure P2 (x:real); begin end;	procedure P4; begin end;

Nous avons indiqué que les gestionnaires d'événements sont des méthodes, les champs du genre événements présents dans les classes Delphi sont en fait des pointeurs de méthode, qui peuvent pointer vers des gestionnaires d'événements.

Le code source apparent  fournit au programmeur. Il permet l'intervention du programmeur sur la fiche et sur ses composants.

Le code intermédiaire caché au programmeur. Il permet l'initialisation automatique de la fiche et de ses composants.

unit  Unit1 ;  interface  uses    Windows, Messages, SysUtils, Variants, Classes,   Graphics, Controls, Forms,   Dialogs, StdCtrls ;     type    TForm1  =  class (TForm)   Button1 :  TButton ;  private   { Déclarations privées }   public   { Déclarations publiques } end;  var    Form1 :  TForm1 ;    implementation   {$R *.dfm} end.

object  Form1 :  TForm1 Left  =  198 Top  =  109 Width  =  245 Height  =  130 Caption  =  'Form1' Color  =  clBtnFace Font.Charset  =  DEFAULT_CHARSET Font.Color  =  clWindowText Font.Height  = - 11 Font.Name  =  'MS Sans Serif' Font.Style  =  [ ] OldCreateOrder  =  False PixelsPerInch  =  96 TextHeight  =  13 object  Button1 :  TButton Left  =  80 Top  =  32 Width  =  75 Height  =  25 Caption  =  'Button1' TabOrder  =  0 end end.

• Le code source visible est celui qui nous sert à programmer nos algorithmes, nos classes, les réactions aux événements.

• Le code intermédiaire est généré au fur et à mesure que nous intervenons visuellement sur l'interface et contient l'initialisation de l'interface (affectations de gestionnaires d'événements, couleurs des fonds, positions des composants, taille, polices de caractères, conteneurs et contenus etc…) il sert au compilateur.

procedure TForm1.Button1Click (Sender: TObject); …
procedure TForm1.Button1MouseMove (Sender: TObject;  Shift:  TShiftState; X,Y: Integer); …
procedure TForm1.Button1KeyPress (Sender: TObject;    var Key: Char); …

 
Voici notre interface au départ :  



Dès que les deux entiers sont entrés, le bouton calcul est activé:
 

 

Lorsque l’on clique sur le bouton calcul, le bouton effacer est activé et les résultats apparaissent dans leurs zones :
 


 

Un clic sur le bouton effacer ramène l’interface à l’état initial.


 

2.2 Réalisation de l’implantation en Delphi

Un graphe événementiel complet de notre interface pourrait être :

Avec comme conventions sur les messages : X1 = exécuter les calculs sur les valeurs entrées. X2 = exécuter l’effacement des résultats. M1 = message à l’edit1 de tout effacer. M2 = message à l’edit2 de tout effacer.

 
Table des actions événementielles associées au graphe :  

Table des états des objets sensibles aux événements, au départ :  

• Nous voulons disposer d’un bouton permettant de lancer le calcul lorsque c’est possible et d’un bouton permettant de tout effacer. Les deux boutons seront désactivés au départ.

• Nous choisissons 6 objets visuels : deux TEdit, Edit1 et Edit2 pour la saisie ; deux Tbutton, ButtonCalcul et Buttoneffacer pour les changements de plans d’action ; deux Tlabel LabelSomme et LabelProduit pour les résultats

Implantation :
 

ButtonCalcul: TButton; Buttoneffacer: TButton; Edit1: TEdit; Edit2: TEdit; LabelSomme: TLabel; LabelProduit: TLabel;

• Nous devons réaliser une synchronisation des entrées dans Edit1 et Edit2 : le déverrouillage (activation) du bouton " ButtonCalcul " ne doit avoir lieu que lorsque Edit1 et Edit2 contiennent des valeurs. Ces deux objets sont sensibles à l’événement OnChange qui indique que le contenu du champ text a été modifié, l’action est indiquée dans le graphe événementiel sous le vocable " changer ".

• La synchronisation se fera à l’aide de deux drapeaux binaires (des booléens)qui seront levés chacun séparément par les TEdit lors du changement de leur contenu. Le drapeau Som_ok est levé par l’Edit1, le drapeau Prod_ok est levé par l’Edit2

Implantation : deux variables booléennes

var      Som_ok,Prod_ok:boolean;




• Le drapeau Som_ok est levé par l’Edit1 lors du changement du contenu de son champ text, sur l’apparition de l’événement OnChange, il en est de même pour le drapeau Prod_ok et l’Edit2:
 
Implantation n°1 du gestionnaire de OnChange :

procedure TForm1.Edit1Change(Sender: TObject); begin   Som_ok:=true; // drapeau de Edit1 levé end;

 

procedure TForm1.Edit2Change(Sender: TObject); begin    Prod_ok:=true; // drapeau de Edit2 levé end;



• Un test vérifiant que les deux drapeaux ont été levés lancera l’activation du ButtonCalcul.

Implantation du test des drapeaux :

procedure TForm1.TestEntrees; {les drapeaux sont-ils levés tous les deux ?} begin  if Prod_ok and Som_ok then   Form1.ButtonCalcul.Enabled:=true  // si et seulement si oui: le bouton calcul est activé end;

  Nous devons alors tester lorsque nous levons un drapeau si l’autre n’est pas déjà levé. Cette opération s’effectue dans les gestionnaires de l’événement OnChange de chacun des Edit1 et Edit2 :
 

Implantation n°2 du gestionnaire de OnChange :

procedure TForm1.Edit1Change(Sender: TObject); begin  Som_ok:=true; // drapeau de Edit1 levé  TestEntrees; end;

procedure TForm1.Edit2Change(Sender: TObject); begin  Prod_ok:=true; // drapeau de Edit2 levé  TestEntrees; end;

• Nous devons gérer l’événement clic sur le bouton calcul qui doit calculer la somme et le produit, placer les résultats dans les deux Tlabels et activer le Buttoneffacer.


Implantation du gestionnaire de OnClick du ButtonCalcul :

procedure TForm1.ButtonCalculClick(Sender: TObject); var S,P:integer; begin  S:=strtoint(Edit1.text); // transtypage : string à integer  P:=strtoint(Edit2.text); // transtypage : string à integer  LabelSomme.caption:=inttostr(P+S);  LabelProduit.caption:=inttostr(P*S);  Buttoneffacer.Enabled:=true // le bouton effacer est activé end;




• Nous codons une procédure dont le rôle est de mettre l’interface à son état de départ indiqué dans la table des états initiaux :

 
Implantation de l’état de départ :

procedure TForm1.RAZTout; begin  with Form1 do  begin   Buttoneffacer.Enabled:=false; //le bouton effacer se désactive   ButtonCalcul.Enabled:=false; //le bouton calcul se désactive   LabelSomme.caption:='0'; // RAZ valeur somme affichée   LabelProduit.caption:='0'; // RAZ valeur produit affichée   Edit1.clear; // message M1   Edit2.clear; // message M2   Prod_ok:=false; // RAZ drapeau Edit2   Som_ok:=false; // RAZ drapeau Edit1  end end;

 
• Un clic sur le Buttoneffacer remet l’interface à son état de départ :

Implantation du gestionnaire de OnClick du Buttoneffacer:

procedure TForm1.ButtoneffacerClick(Sender: TObject); begin  RAZTout; end;

• A la création de l’interface on positionne tous les objets à l’état initial (nous choisissons l’événement OnCreate de création de la fiche pour lancer cette initialisation):

Implantation du gestionnaire de OnCreate de la fiche Form1:

procedure TForm1.FormCreate(Sender: TObject); begin  RAZTout; end;




Delphi.Interfaces \Calcul.V.1.dlfi

Lorsque nous essayons notre interface nous constatons que nous avons un problème de sécurité à deux niveaux dans notre saisie.

• Le premier niveau est celui des corrections apportées par l’utilisateur (effacement de chiffres déjà entrés) et la synchronisation avec l’éventuelle vacuité d’au moins un des champs text après une telle modification : en effet l’utilisateur peut effacer tout le contenu d’un " Edit " et lancer alors le calcul, provoquant ainsi des erreurs.
• Le deuxième niveau classique est celui du transtypage incorrect, dans le cas où l’utilisateur commet des fautes de frappe et rentre des données autres que des chiffres (des lettres ou d’autres caractères du clavier).

   
2.3 Améliorations de sécurité du premier niveau par plan d’action

Delphi.Interfaces \Calcul.V.2.dlfi

Nous protégeons les calculs dans le logiciel, par un test sur la vacuité du champ text de l’Edit ; dans le cas favorable où le champ n’est pas vide, on autorise la saisie ; dans l’autre cas on désactive systématiquement le ButtonCalcul et l’on abaisse le drapeau qui avait été levé lors de l’entrée du premier chiffre, ce qui empêchera toute erreur ultérieure. L’utilisateur comprendra de lui-même que tant qu’il n’y a pas de valeur dans les entrées, le logiciel ne fera rien et on ne passera donc pas au plan d’action suivant (calcul et affichage). Cette amélioration s’effectue dans les gestionnaires d’événement OnChange des deux TEdit.

Implantation n°2 du gestionnaire de OnChange :

procedure TForm1.Edit1Change(Sender: TObject); begin  if Edit1.text<>'' then// champs text non vide ok !  begin   Som_ok:=true;   TestEntrees;  end  else  begin   ButtonCalcul.enabled:=false; // sinon bouton désactivé   Som_ok:=false; // drapeau de Edit1 baissé  end end;

procedure TForm1.Edit1Change(Sender: TObject); begin  if Edit1.text<>'' then// champs text non vide ok !  begin   Som_ok:=true;   TestEntrees;  end  else  begin   ButtonCalcul.enabled:=false; // sinon bouton désactivé   Som_ok:=false; // drapeau de Edit1 baissé  end end;

 

procedure TForm1.Edit2Change(Sender: TObject); begin  if Edit2.text<>'' then // champs text non vide ok !  begin   Prod_ok:=true;   TestEntrees;  end  else  begin   ButtonCalcul.enabled:=false; // sinon bouton désactivé   Prod_ok:=false; // drapeau de Edit2 baissé  end end;


Regroupement du code
 
Soit la méthode privée Autorise possédant deux paramètres, le premier est la référence d'un des deux TEdit, le second le drapeau booléen associé :

procedure  TForm1.Autorise ( Ed  :  TEdit  ; var  flag  : boolean  ) ;
begin
   if  Ed.text < ' ' then  // champ text non vide ok !
    begin
     flag  := true ;
     TestEntrees ;
   end
   else
   begin
     ButtonCalcul.enabled := false ;  //bouton désactivé
     flag := false ;  // drapeau de Ed baissé
    end
end;

Nouvelle implantation n°2 du gestionnaire de OnChange :

procedure  TForm1.Edit1Change( Sender:  TObject) ;
begin
    Autorise ( Edit1 , Som_ok ) ;
end;
procedure  tform1.edit2change( sender:  tobject) ;
begin
    Autorise ( Edit2 , Prod_ok ) ;
end;

Code final où tout est regroupé dans la classe TForm1

unit  UFcalcul ;
 
 interface
 
 uses
   Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,   StdCtrls, ExtCtrls ;
  
 type
   TForm1 =  class  ( TForm )
  Edit1 :  TEdit ;
   Edit2 :  TEdit ;
   ButtonCalcul :  TButton ;
   LabelSomme :  TLabel ;
   LabelProduit :  TLabel ;
   Buttoneffacer :  TButton ;
  procedure  FormCreate( Sender:  TObject) ;
  procedure  Edit1Change( Sender:  TObject) ;
  procedure  Edit2Change( Sender:  TObject) ;
  procedure  ButtonCalculClick( Sender:  TObject) ;
  procedure  ButtoneffacerClick( Sender:  TObject) ;
 private     { Déclarations privées }
   Som_ok , Prod_ok  :
   procedure  TestEntrees ;
  procedure  RAZTout ;
  procedure  Autorise ( Ed  :  TEdit  ; var  flag  : boolean  ) ;
 public     { Déclarations publiques }
end;

implementation
{ --------------- Méthodes privées ---------------------}
  procedure  TForm1.TestEntrees ;
  {les drapeaux sont-ils levés tous les deux ?}
  begin
  if   Prod_ok  and  Som_ok  then
    ButtonCalcul.Enabled := true   //  si oui: le bouton calcul est activé
  end;
 
 procedure  TForm1.RAZTout ;
 begin 
   Buttoneffacer.Enabled := false ;  //le bouton effacer se désactive
   ButtonCalcul.Enabled := false ;  //le bouton calcul se désactive
   LabelSomme.caption := '0';  // RAZ valeur somme affichée
   LabelProduit.caption := '0';  // RAZ valeur produit affichée
   Edit1.clear ;  // message M1
   Edit2.clear ;  // message M2
   Prod_ok := false ;  // RAZ drapeau Edit2
   Som_ok := false ;  // RAZ drapeau Edit1
  end;
 
 procedure  TForm1.Autorise ( Ed  :  TEdit  ; var  flag  : boolean  ) ;
 begin
  if  Ed.text < ' ' then  // champ text non vide ok !
   begin
    flag  := true ;
    TestEntrees ;
  end
  else
  begin
    ButtonCalcul.enabled := false ;  //bouton désactivé
    flag := false ;  // drapeau de Ed baissé
   end
 end;
 
  { ------------------- Gestionnaires d'événements -------------------}
  procedure  TForm1.FormCreate( Sender:  TObject) ;
 begin
   RAZTout ;
 end;
 
 procedure  TForm1.Edit1Change( Sender:  TObject) ;
 begin
   Autorise ( Edit1 , Som_ok ) ;
 end;
 
 procedure  TForm1.Edit2Change( Sender:  TObject) ;
 begin
   Autorise ( Edit2 , Prod_ok ) ;
 end;
 
 procedure  TForm1.ButtonCalculClick( Sender:  TObject) ;
 var  S , P  : integer ;
 begin
   S := strtoint(Edit1.text) ;  // transtypage : string è integer
   P := strtoint(Edit2.text) ;  // transtypage : string è integer
   LabelSomme.caption := inttostr(P + S) ;
   LabelProduit.caption := inttostr(P * S) ;
   Buttoneffacer.Enabled := true  // le bouton effacer est activé
  end;
 
 procedure  TForm1.ButtoneffacerClick( Sender:  TObject) ;
 begin
   RAZTout ;
 end;
 
end.

Un gestionnaire d'événement centralisé grâce au :
-    polymorphisme d'objet
-    pointeur de méthode

Chaque Edit possède son propre gestionnaire de l'événement OnChange :

procedure  TForm1.Edit1Change( Sender:  TObject) ;
begin
    Autorise ( Edit1 , Som_ok ) ;
end;
procedure  TForm1.Edit2change(  Sender:  tobject) ;
begin
    Autorise ( Edit2 , Prod_ok ) ;
end;

On peut avoir envie de mettre en place un gestionnaire unique de l'événement OnChange, puis de le lier à chaque zone de saisie Edit1 et Edit2 (souvenons-nous qu'un champ d'événement est un pointeur de méthode) :
 

Nous définissons d'abord une méthode public par exemple, qui jouera le rôle de gestionnaire centralisé d'événement,  nous la nommons TexteChange.


Cette méthode pour être considérée comme un gestionnaire de l'événement OnChange, doit obligatoirement être compatible avec le type de l'événement Onchange. Une consultation de la documentation Delphi nous indique que :


property OnChange: TNotifyEvent;


L'événement OnChange est du même type que l'événement OnClick ( TnotifyEvent = procedure(Sender:Tobject) of object ), donc notre gestionnaire centralisé TexteChange doit avoir l'en-tête suivante :

         procedure TexteChange ( Sender : Tobject );

Le paramètre Sender est la référence de l'objet qui appelle la méthode qui est passé automatiquement lors de l'exécution, en l'occurrence ici lorsque Edit1 appellera ce gestionnaire c'est la référence de Edit1 qui sera passée comme paramètre, de même lorsqu'il s'agira d'un appel de Edit2.

Implantation du gestionnaire centralisé :

procedure  TForm1.TexteChange( Sender:  TObject) ;
  begin
   if   Sender is  TEdit  then
   begin
    if  ( Sender as  TEdit ) = Edit1  then
      Autorise ( ( Sender as  TEdit ) , Som_ok ) ;
    else
      Autorise ( ( Sender as  TEdit ) , Prod_ok ) ;
   end
  end;    

On teste si l'émetteur Sender est bien un TEdit,

polymorphisme d'objet :


Si l'émetteur est Edit1 on le transtype  en TEdit pour pouvoir le passer en premier paramètre à la méthode Autorise sinon c'est Edit2 et l'on fait la même opération.


On lie maintenant ce gestionnaire à chacun des champs OnChange de chaque TEdit dès la création de la fiche :

procedure  TForm1.FormCreate( Sender:  TObject) ;
begin
    RAZTout ;
    Edit1.OnChange  :=  TexteChange  ;
    Edit2.OnChange  :=  TexteChange  ;
end;   

    
pointeur de méthode


chaque champ Onchange pointe vers le même gestionnaire (méthode)

procedure  TForm1.FormCreate( Sender:  TObject) ;
  begin
    RAZTout ;
    Edit1.OnChange  :=  TexteChange  ;
    Edit2.OnChange  :=  TexteChange  ;
  end;  

 

2.4 Améliorations de sécurité du second niveau par filtrage

Nous pouvons améliorer cet état de la saisie des caractères chiffres en construisant un analyseur de filtrage qui ne conserve que les caractères valides tapés dans chaque Tedit. La syntaxe de l’entrée est fournie par le diagramme suivant :

Nous construisons un AEFD reconnaissant ces chiffres et il nous servira de système de filtrage des caractères entrés.
 
L’AEFD de filtrage :

procedure Filtrage(entree :string;var resultat:string); var i:integer;     saisie :string;     CarValides:set of char; begin  CarValides:=['0'..'9']; // les chiffres seulement  saisie:=entree;  if length(saisie)<>0 then  begin   i:=1;   while saisie[i] in CarValides do i:=i+1; // le premier caractère non juste   if not(saisie[i] in CarValides)then delete(saisie,i,1);  end;  resultat:=saisie end;


 
Implantation n°3 du gestionnaire de OnChange :

procedure TForm1.Edit1Change(Sender: TObject); var sortie :string ; begin  Filtrage(Edit1.text,sortie);  Edit1.text:=sortie;  Som_ok:=true; // drapeau de Edit1 levé  TestEntrees; end;

procedure TForm1.Edit2Change(Sender: TObject); var sortie :string ; begin  Filtrage(Edit2.text,sortie);  Edit2.text:=sortie;  Prod_ok:=true; // drapeau de Edit2 levé  TestEntrees; end;

Le filtrage est effectué lors de la saisie des entrées dans les gestionnaires d’événement OnChange des deux Tedit. Chaque changement du contenu du champ text d’un Edit (comme l’entrée d’un nouveau caractère) provoque le déclenchement de l’événement OnChange qui rejette alors les caractères non valides.

 
Delphi.Interfaces \Calcul.V.3.1.dlfi
 

Implantation n°4 du gestionnaire de OnChange :

procedure TForm1.Edit1Change(Sender: TObject); var sortie :string ; begin  Filtrage(Edit1.text,sortie);  Edit1.text:=sortie;  if Edit1.text<>'' then// champs text non vide ok !  begin   Som_ok:=true;   TestEntrees;  end  else  begin   ButtonCalcul.enabled:=false; // sinon bouton désactivé   Som_ok:=false; // drapeau de Edit1 baissé  end end;

procedure TForm1.Edit2Change(Sender: TObject); var sortie :string ; begin  Filtrage(Edit2.text,sortie);  Edit2.text:=sortie;  if Edit2.text<>'' then // champs text non vide ok !  begin   Prod_ok:=true;   TestEntrees;  end  else  begin   ButtonCalcul.enabled:=false; // sinon bouton désactivé   Prod_ok:=false; // drapeau de Edit2 baissé  end end;

En combinant la sécurité du premier et du second niveau dans le gestionnaire d’événement OnChange nous obtenons un niveau acceptable de sécurisation de notre logiciel grâce à son interface. Il nous manque encore une protection sur les débordements de calcul (dépassement de l’intervalle sur les integer qui ne provoquent pas d’incidents mais induisent des résultats erronés) pour assurer une sécurité optimale de fiabilité.

Pour terminer la réalisation de cet exemple, nous pouvions aussi procéder à un autre genre de protection sans avoir à écrire un analyseur de filtrage (qui était dans ce cas un AEFD), en utilisant directement les facilités de protection fournies par les exceptions.
 
 
 

2.5 Améliorations de sécurité du second niveau par exceptions

On déporte le problème de la protection non plus sur le séquencement des plans d’actions mais au cœur même de l’action en protégeant directement le code où l’erreur se produit par un gestionnaire d’exception. Afin de présenter un traitement complet de l’exemple nous anticipons légèrement sur le chapitre sur la programmation défensive ; le lecteur pourra donc en première lecture sauter ce paragraphe s’il le désire et y revenir plus tard.

 
Delphi.Interfaces \Calcul.V.3.2.dlfi

On fait exécuter le programme en provoquant volontairement l’erreur (on entre des lettres au lieu de chiffres) ; le logiciel signale la levée de l’exception EconvertError et nous programmons le gestionnaire associé à cette levée d’exception. Elle apparaît lorsque la fonction StrtoInt essaye de transtyper le champ text de l’Edit et échoue ; c’est donc cette ligne de code qui doit être protégée :
 

try    S:= StrtoInt(edit1.text);  except on EconvertError do  begin   Edit1.text:='0';   S:=0  end end;

Nous avons décidé ici de mettre 0 dans le champ text de l’Edit1 et de forcer la valeur de la variable de calcul S à 0. Ce traitement est identique pour la variable P à partir du champ text de l’Edit2. Ces deux traitements de protection sont effectués lors du click sur ButtonCalcul (traitement de l’erreur après saisie).
 

procedure TForm1.ButtonCalculClick(Sender: TObject); var S,P:integer; begin  try   S:= StrtoInt(edit1.text);   except on EconvertError do   begin    Edit1.text:='0';    S:=0   end  end;  try   P:= StrtoInt(edit2.text);   except on EconvertError do   begin    Edit2.text:='0';    P:=0   end  end;  LabelSomme.caption:=inttostr(P+S);  LabelProduit.caption:=inttostr(P*S);  Buttoneffacer.enabled:=true // le bouton effacer est activé end;{ButtonCalculClick}


 

Conclusion

Ce logiciel d’interface simplifiée met en œuvre tous les concepts de base d’une interface à l’exception des temps d’attente qui ne sont pas pertinents dans cet exemple :
 

• les objets d’entrée-sortie sont fournis par le RAD,
• le pilotage a été réalisé à l’aide du graphe événementiel,
• l’enchaînement a été implanté à travers la synchronisation dans le graphe événementiel,
• une partie de la sécurité a été obtenue en décomposant l’interaction homme-logiciel en deux plans d’action : le plan de saisie et le plan de calcul-affichage.


Un chapitre spécial est consacré à la programmation défensive afin de nous aider à améliorer la résistance aux erreurs de nos logiciels de communication. Nous allons dans ce qui suit proposer une méthode systématisée de mise en œuvre des concepts d’interaction et de pilotage dans une interface.