Tivoli Service Desk 6.0 Developer's Toolkit - Guide de programmation TSD Script

Chapitre 5 : Programmation événementielle

Retour à la table des matières


Introduction

La programmation événementielle (event-driven) est utilisée pour développer des applications destinées aux plateformes et réseaux à interface utilisateur graphique. Dans TSD Script, les fonctionnalités d'interface utilisateur sont essentiellement commandées par les événements. Pour illustrer les concepts d'un programme commandé par les événements, étudions la suite des événements se produisant dans un programme interactif conçu pour recevoir des informations de l'utilisateur :

  1. L'application crée une fenêtre principale avec un menu.
  2. L'application attend que l'utilisateur opère une sélection dans le menu.
  3. L'utilisateur sélectionne une commande dans le menu (un événement).
  4. L'application répond à la demande de l'utilisateur.
  5. L'application attend.

Définition

Dans un environnement commandé par les événements, une application est un ensemble de fenêtres individuelles. On construit donc une application en assemblant plusieurs fenêtres capables de dialoguer entre elles.

A chaque fenêtre est associée une routine que l'on appelle gestionnaire d'événements. Lorsqu'un utilisateur interagit avec une fenêtre, c'est son gestionnaire qui traite l'événement généré par cette interaction. L'interaction entre l'utilisateur et l'ordinateur est dynamique. C'est-à-dire que les événements ou les processus ont lieu immédiatement et simultanément, en fonction des besoins.

Influences de la conception orientée objet

La construction des programmes commandés par les événements s'appuie souvent sur les concepts de la programmation objet :

L'encapsulation des objets favorise leur réutilisation, car il n'est pas nécessaire de les "réinventer" chaque fois qu'on souhaite les utiliser.

Les messages transitant via le réseau peuvent être traités de la même manière que les fenêtres et les gestionnaires d'événements. Autrement dit, il est possible de traiter comme un objet encapsulé chaque message réseau et chaque connexion réseau. Pour plus d'informations sur les fonctions réseau de TSD Script, reportez-vous au Chapitre 11, Concepts relatifs aux réseaux.

Pour construire une application commandée par les événements, on assemble plusieurs objets fenêtres et on met en place un mécanisme d'échange de messages pour leur permettre de communiquer. TSD Script dispose de puissantes fonctions de création de fenêtres encapsulées et d'échange de messages.

Gestionnaires d'événements

Les gestionnaires d'événements sont utilisés dans TSD Script et dans la boîte à outils du développeur (Developer's Toolkit) pour prendre en charge un environnement commandé par des événements. Dans un tel environnement, un événement (tel que l'utilisation d'une touche ou un clic de la souris) déclenche une réponse de l'application (par exemple, l'ouverture d'une boîte de dialogue ou la sélection d'une entrée dans une zone). Pour traiter les événements, chaque application utilise des gestionnaires d'événements spécifiques. Ils sont appelés par le système lorsque celui-ci a un événement à livrer à l'application. Un objet ou une fenêtre peut posséder plusieurs gestionnaires d'événements.

Définition de gestionnaires d'événements

Vous définissez un gestionnaire d'événements dans la section ROUTINES de votre programme TSD Script. Pour le rendre actif, vous devez l'associer à une source d'événement telle qu'une fenêtre, une boîte de dialogue ou un service réseau.

Caractéristiques des gestionnaires d'événements

Une routine EVENT contient l'ensemble des instructions TSD Script qui servent à la construction d'un gestionnaire d'événements. Comme les procédures et les fonctions, un gestionnaire d'événements est une suite d'instructions TSD Script encadrées par un bloc ACTIONS...END. Comme les autres blocs TSD Script, un gestionnaire d'événements peut également contenir :

Les particularités d'un gestionnaire d'événements comprennent :

$Handle

Les descripteurs sont contenus dans le paramètre $Handle et transmis sous cette forme au gestionnaire d'événements.

$Handle est un paramètre implicite qui est transmis à chaque gestionnaire d'événements et qui identifie de manière unique la fenêtre ou la connexion réseau recevant le message.

Paramètres implicites

Réception des paramètres d'événement

Chaque fois qu'un gestionnaire d'événements est informé d'un événement, il reçoit deux éléments d'information essentiels :

Le descripteur peut être celui d'une autre fenêtre ou d'une connexion réseau, selon la manière dont le gestionnaire d'événements est déclaré.

Informations spécifiques de l'événement

Outre les paramètres $Handle et $Event, un gestionnaire d'événements peut recevoir des informations complémentaires, spécifiques à l'événement considéré.

Par exemple, un événement $MsgSize est accompagné de deux données supplémentaires :

Ces données supplémentaires sont toujours accessibles via l'événement $EventParm, qui prend deux arguments :

Par conséquent, une expression comme $EventParm(1,Integer) permet d'obtenir la largeur d'une nouvelle fenêtre lors du traitement d'un événement $MsgSize.

Il existe des fonctions de raccourci pour de nombreux paramètres d'événement des messages définis par le système. Il existe aussi d'autres paramètres implicites pour les formulaires.

Données d'instance

L'utilisation de gestionnaires d'événements implique également la manipulation de données d'instance. Il s'agit des données qui sont associées à une fenêtre ou à une connexion réseau particulières. Comme le montre l'exemple d'application figurant à la fin de ce chapitre, les données d'instance constituent souvent un enregistrement. Elles appartiennent à la fenêtre et leur durée d'existence est exactement la même que la durée d'ouverture de la fenêtre.

Les données d'instance peuvent être initialisées dans l'appel utilisé pour créer la fenêtre, WinCreate. Par exemple :

WinCreate($Desktop,context.mainWindow,
          MainEvent {context},
          1,1,100,30,'Titre de la fenêtre principale',
          BitOr($WinBorder,$WinResize,
                $WinTitle,$WinSysMenu,
                $WinMinMax,$WinIconBar,$WinTaskList)); 

Gestionnaires d'événements et données d'instance

Lorsqu'il traite une instruction telle que celle de l'exemple précédent, TSD Script analyse la déclaration du gestionnaire d'événements indiqué, MainEvent. Il détermine que MainEvent prend comme argument formel un enregistrement du type ContextRecord. TSD Script en déduit qu'il faut réserver suffisamment de place pour un ContextRecord dans les données d'instance de la nouvelle fenêtre.

TSD Script regarde ensuite à droite du nom du gestionnaire d'événements, dans l'instruction WinCreate, et trouve une forme d'initialisation - {context}. Celle-ci provoque la copie, dans les données d'instance de la fenêtre, du contenu de la variable enregistrement context.

Remarque : Les variables qui apparaissent dans cette forme doivent être du même type que l'argument formel du gestionnaire d'événements.

Chaque fois qu'un gestionnaire d'événements est appelé, il reçoit une référence aux données d'instance de la fenêtre. De cette manière, il peut inspecter le contenu en cours des données d'instance et y apporter des modifications. Un processus d'initialisation similaire est disponible pour les objets d'interface autres que de type Windows, qui utilisent des gestionnaires d'événements (par exemple, les connexions réseau).

Avec la combinaison de données d'instance et d'un gestionnaire d'événements, les fenêtres et les connexions réseau TSD Script se comportent comme des objets encapsulés. Les implications pratiques de ce comportement sont les suivantes :

Remarque : Evitez d'utiliser des variables globales dans un programme TSD Script. Servez-vous plutôt des données d'instance des fenêtres et de la transmission de messages pour disséminer les informations dans le programme.

Conservation d'éléments en cours

Supposons que vous vouliez assurer la conservation d'un élément en cours. Il existe au moins trois façons d'y parvenir :

SendMessage(mainWindow,QUERY_CURRENT_ID,current_ID); 

Il faudrait alors que QUERY_CURRENT_ID soit une variable globale telle que :

CONSTANTS
  QUERY_CURRENT_ID IS $MsgUser+1;

et que la fenêtre principale soit en mesure de prendre en charge ce message comme suit :

EVENT MainEvent(REF context: ContextRecord) IS 
    VARIABLES
      iconList: List of String;
    ACTIONS
      WHEN $Event IS $MsgCreate THEN
        iconList:={'ADDINV.ICO','SRCHINV.ICO',
                   'REPORTS.ICO'): LIST OF STRING;
        WinSetIconBar($Handle,iconList);
      ELSWHEN $MsgSelect THEN
        WHEN $EventParm(1,Integer) IS 1 THEN
          CreateAddWindow;
        ELSWHEN 2 THEN
          CreateSearchWindow;
        ELSWHEN 3 THEN
          CreateReportWindow;
      END; 
      ELSWHEN QUERY_CURRENT_ID THEN
        $EventParm(1,String):=context.current_ID;
        END; 
    END (* Main Event *); 

Dans cet exemple, MainEvent a été étendu pour inclure un test de l'événement QUERY_CURRENT_ID. Lorsqu'il détecte un tel événement, MainEvent copie la valeur du champ current_ID des données d'instance de la fenêtre principale dans la variable chaîne (string) transmise comme troisième argument de SendMessage par la routine appelante, qui correspond en fait au premier paramètre d'événement. Une fois que cette routine a terminé l'exécution de sa commande SendMessage, le troisième argument contient la valeur copiée par le gestionnaire MainEvent.


Tivoli Service Desk 6.0 Developer's Toolkit - Guide de programmation TSD Script

Retour à la table des matières

Copyright