Visual Basic .Net:Programmation événementielle

Nous ne sommes pas au bout de peines (ni au bout de nos joies). Toute cette sombre histoire d'objets cache une autre drôle de plaisanterie, qui va radicalement transformer la manière dont les procédures d'un programme vont être exécutées, et du coup, la manière dont les programmeurs vont devoir concevoir leurs applications.

C'est le deuxième aspect dont je parlais au début de ce chapitre, aspect qui est lié à la programmation objet, mais qui ne se confond pas tout à fait avec elle. De quoi s'agit-il ?

Rappelons-nous comment notre code était organisé dans un langage procédural traditionnel. Plutôt qu'une immense procédure fait-tout, comportant des redites de code, nos applications, dès lors qu'elles devenaient un peu joufflues, étaient organisées en modules séparés : sous-procédures et fonctions (lesquelles, je le rappelle, ne sont jamais qu'un cas particulier de sous-procédures).

Parmi ces diverses procédures, il s'en trouvait une qui jouait un rôle particulier : la procédure principale (appelée Main dans la plupart des langages). C'est elle qui était exécutée lors du lancement de l'application. Et c'est elle qui tout au long du programme, telle un chef d'orchestre, déclenchait les autres procédures et les autres fonctions.

Le point important dans cette affaire, c'est qu'une fois l'application lancée, une procédure donnée ne pouvait s'exécuter que si une ligne de code, quelque part, en commandait le déclenchement. L'utilisateur n'avait aucune espèce de moyen d'influencer directement l'ordre dans lequel les procédures allaient être exécutées.

Tout ceci va être remis en question avec les langages objet. Non qu'on ne puisse plus créer encore des procédures et des fonctions, et appeler les unes via les autres par des instructions adéquates ; je le rappelle, il n'y a rien qu'on pouvait faire avec un langage procédural qu'on ne puisse faire avec un langage objet. Mais avec un langage objet, il y a des choses qu'on peut faire qui sont véritablement inédites. En l'occurrence, la grande nouveauté, c'est qu'on va pouvoir organiser le déclenchement automatique de certaines procédures en réponse à certaines actions de l'utilisateur sur certains objets.

Pour comprendre cela, le plus simple est de penser que certains objets ont une caractéristique particulière : ils se voient à l'écran. Ainsi, un logiciel comme Windows est en fait truffé de ce genre d'objets ! Les boutons, les menus, les fenêtres, les cases à cocher, tout cela constitue une armada d'objets visibles, et surtout, capables de réagir à diverses sollicitations de l'utilisateur via le clavier ou la souris. Les programmeurs qui ont écrit Windows ont donc prévu, et écrit, des myriades de morceaux de code (des procédures) qui se déclenchent à chaque fois que l'utilisateur accomplit telle action sur tel type d'objet. Donc, je le répète, concevoir une application événementielle, c'est concevoir des procédures qui se déclencheront automatiquement à chaque fois que l'utilisateur effectuera telle action sur tel objet qu'on aura mis à sa disposition

[modifier]

Remarque

Dans les phrases qui précèdent, les mots "à chaque fois que" sont essentiels. Il faut impérativement les avoir en tête lorsqu'on écrit une application objet.

Faute de quoi on mélange tout, et en particulier, on se met à écrire des boucles là où il n'y a qu'une simple procédure..

[modifier]

Définition action

Une action sur un objet capable de déclencher une procédure s'appelle un événement.

Voilà pourquoi ce type de programmation porte le nom de programmation événementelle. Par ailleurs, il est à noter que les événements qu'un objet donné est capable de gérer ont été définis dans la classe qui a servi à créer l'objet.

[modifier]

Remarque importante

Tous les objets capables de gérer un événement ne sont pas forcément des objets visibles à l'écran. Dans le même ordre d'idées, tous les événements ne correspondent pas forcément à des actions de l'utilisateur via le clavier ou la souris. Mais pour commencer, on peut très bien s'accommoder de ces approximations.

[modifier]

Le diagramme TOE

Lors de la conception d'un programme objet, une des premières tâches du développeur va donc être de concevoir l'interface utilisateur. C'est-à-dire de prévoir quels objets vont être mis à la disposition de l'utilisateur, de prévoir les actions que l'utilisateur pourra effectuer sur ces objets (les événements) et de prévoir les tâches que le programme devra accomplir lors de ces événements.

[modifier]

Remarque incidente

Pour le moment, nous nous contenterons de considérer que nos applications emploient l'arsenal des objets utilisés par Windows, et uniquement cela. Ces objets (plus exactement, ces classes) seront donc tout prêts à l'emploi. Leurs propriétés, leurs méthodes et les événements qu'ils sont capables de gérer ont été définis par Windows, c'est-à-dire par Visual Basic (qui nous sert en quelque sorte d'intermédiaire vis-à-vis de Windows, qui parle un langage trop abscons).

En réalité, dans un programme Visual Basic, on peut utiliser des tas d'autres objets (classes), on peut même en fabriquer soi-même. Nous verrons cela... plus tard. Pour le moment, contentons-nous de la trousse à outils de base que Visual Basic met à notre disposition, et ce sera déjà bien suffisant.

Ainsi, nous pouvons prévoir qu'il faudra que la fenêtre de notre application se présente comme ceci ou comme cela, qu'il devra y avoir ici un bouton, là des boutons radios, ici une zone de liste, etc. Et il faut également prévoir qu'un clic sur tel bouton déclenchera tel ou tel calcul, qu'un choix dans telle liste devra mettre à jour telle ou telle zone, etc.

Le document synthétique, sous forme de tableau, qui reprend toutes ces informations, s'appelle un diagramme T.O.E., pour Tâche, Objet, Événement. C'est un document préalable indispensable à la programmation d'une application événementielle. Il comporte trois colonnes. Dans la première, on dresse la liste exhaustive des tâches que doit accomplir l'application. Dans la seconde, en regard de chaque tâche à accomplir, on porte, le cas échéant, le nom de l'objet qui en sera chargé. Et dans la troisième, en regard de chaque objet, on écrit le cas échéant, mais oui, l'événement correspondant. Vous l'aviez deviné, décidément vous êtes trop forts.

[modifier]

Remarque importante

Rien, absolument rien, ne dit qu'un objet doit être associé à un événement et à un seul. Il peut très bien y avoir des objets qui ne gèrent aucun événement. De même, certains objets peuvent très bien être amenés à gérer plusieurs événements différents, qui correspondront donc à autant de procédures différentes.

[modifier]

La syntaxe

Comment effectue-t-on la liaison entre une procédure et un événement ? C'est extrêmement simple : cette liaison figure en toutes lettres dans l'en-tête de la procédure, via le mot-clé Handles (que l'on peut traduire par "gère"). Ainsi, une procédure non événementielle, toute bête, toute simple, que j'appelle Calcul, aura la tête suivante :

Private Sub Calcul()
 instructions
End Sub

Pour que cette procédure s'exécute à chaque fois que l'on clique sur le bouton nommé Résultat, il suffira que la procédure se présente ainsi :

Private Sub Calcul() Handles Résultat.Click
 instructions
End Sub

Si d'aventure, plusieurs événements différents doivent déclencher la même procédure, ce n'est pas du tout un souci. Il suffit de séparer tous les événements concernés par des virgules après le mot clé Handles. Si, par exemple la remise à zéro doit être effectuée en cas de clic sur le bouton Résultat, mais aussi de clic sur le bouton Annulation, on aura :

Private Sub RemiseAZero() Handles Résultat.Click, Annulation.Click
 instructions
End Sub

Et voilà le travail. En réalité, il y a juste une petite subtilité supplémentaire. C'est que lorsqu'un événement déclenche une procédure, Visual Basic prévoit automatiquement un passage de paramètres depuis l'événement jusqu'à la procédure, passage de paramètres sans lequel on serait parfois bien embêté. La syntaxe complète d'une procédure événementielle sera donc typiquement :

Private Sub RemiseAZero(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Résultat.Click, Annulation.Click
 instructions
End Sub

Où, à chaque exécution de la procédure suite à un événement : :

sender est un paramètre en entrée (par valeur) qui désigne l'objet qui a déclenché l'événement
e représente un paramètre en entrée (par valeur) qui spécifie les conditions de l'événement.

Gardons ces généralités en tête ; nous aurons naturellement l'occasion de revenir plus en détail sur ces deux paramètres et la manière de s'en servir.

Si vous avez compris ce second mécanisme que sont les procédures événementielles, alors vous avez alors pigé 45 % supplémentaires du cours. Donc, avec les 45 % précédents, on en est à 90 %. Tout le reste, c'est de la petite bière. Puisque je vous le dis.

[modifier]