Visual Basic .Net:Evénements clavier

Dans un certain nombre d'applications, on peut souhaiter attribuer certaines conséquences à la frappe de certaines touches du clavier. Par exemple, la touche F1 doit ouvrir le fichier d'aide. Autre exemple, vous pilotez en temps réel les mouvement de Zorglub, le grandiose vaisseau de l'hyperespace, grâce aux touches de direction.

Tout cela suppose que la frappe de telle ou telle touche du clavier soit interprétée par le logiciel comme un événement. Aucun problème, Billou s'occupe de nous, et pour ce faire nous offre trois événements, pas un de moins.

[modifier]

Evénements

Keypress : cet événement détecte le fait qu'un caractère a été frappé au clavier.
Keydown et Keyup : ces deux événements, qui fonctionnent de pair, se déclenchent lorsqu'une touche du clavier est enfoncée (Keydown) ou relâchée (Keyup). La caractéristique de ces deux événements est qu'ils détectent l'état physique du clavier.

Cela signifie que les touches ne produisant pas de caractères, telles les touches de fonction, ou les touches de direction, ne génèrent pas l'événement Keypress, mais génèrent les événements KeyDown et KeyUp

[modifier]

Paramètres en entrée

Revenons-en à présent à un aspect sur lequel, jusqu'à maintenant, nous ne nous sommes pas arrêtés autant qu'il le mérite : je veux parler des paramètres en entrée des procédures événementielles.

Pour ce qui est des généralités sur les paramètres en entrée d'une procédure, je ne vous ferai pas l'affront de vous réexpliquer ce dont il s'agit. Vous êtes blindés en Algorithme, et je sais que jamais vous ne vous seriez lancé dans ce cours sans être des cadors sur la question. Passons donc rapidement, comme il sied de le faire en présence d'experts.

Dans une procédure événementielle, nous avons toujours pu constater, quel que soit l'événement, que VB organisait le passage de deux paramètres : le fameux Sender, et le mystérieux e.

Fameux, le Sender, puisqu'on a déjà vu qu'il s'agissait d'une variable faisant référence à l'objet qui a déclenché la procédure. Ceci s'est avéré particulièrement utile lorsque plusieurs objets étaient branchés (par exemple en cas de clic) sur la même procédure : le paramètre Sender nous a alors permis, au sein de cette procédure, d'identifier lequel des contrôles avait déclenché la procédure, et d'avoir accès à ses propriétés.

Le paramètre e est également une variable qui désigne un objet. Mais cet objet n'est pas le contrôle qui a déclenché la procédure (évidemment, puisque c'est Sender, on ne va pas mettre deux fois la même information sous deux noms différents, eh, patate). D'ailleurs, le paramètre objet e n'est pas un contrôle du tout. Il représente, si l'on veut, les conditions, ou les résultats, comme on préfère, de l'événement lui-même. La nature de ses propriétés variera donc d'un événement à l'autre.

S'il s'agit d'un événement Click, disons-le tout net, il n'y a pour ainsi dire aucune propriété dans e, car rien n'est plus tristement banal et sans caractéristiques particulières qu'un clic. En revanche, s'il s'agit d'un événement clavier, c'est tout de suite beaucoup plus intéressant.

[modifier]

Exemple

Par exemple, lors d'un KeyDown ou d'un KeyUp, e possèdera tout un tas de propriétés booléennes (Shift, Alt) ou numériques (Keycode) nous permettant de savoir dans les menus détails quel était l'état du clavier lors du déclenchement de l'événement. Lors d'un KeyPress, nous trouvons pour le paramètre en entrée e la propriété caractère KeyChar, contenant le caractère généré par la touche pressée.

Ainsi, le code qui afficherait dans une MessageBox une à une les touches frappées au clavier serait :

Private Sub Button1_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles Button1.KeyPress
 Dim tutu As Integer
 tutu = MsgBox(e.KeyChar, vbOKOnly, "Touche frappée :")
End Sub

Il nous reste toutefois un petit détail à régler avant d'en avoir définitivement terminé avec les événements clavier. Imaginons que nous voulions réaliser un "appel à l'aide" avec la touche F1. Pas le choix, nous devrons passer par un KeyDown (car la touche F1 n'engendrant aucun caractère, elle ne produit donc pas d'événement Keypress). Mais là où ça coince, c'est quand on réfléchit à quel contrôle nous devrons affecter l'événement. En effet, le focus étant supposé pouvoir se trouver sur bien des endroits de la Form lorsqu'on appuiera sur la touche F1, il faudrait en bonne logique créer une procédure Chmoll.KeyDown pour chacun des contrôles Chmoll susceptibles de posséder le focus. On n'est pas rendu.

Heureusement, il y a une autre possibilité : faire en sorte que la Form court-circuite tous les contrôles qui se trouvent sur elle en cas de frappe de touche au clavier. Il suffit pour cela de régler sa propriété KeyPreview (qu'on pourrait traduire approximativement par "interception du clavier") à True. On n'a plus alors qu'à écrire une seule procédure, celle qui gère l'événement KeyDown sur la Form. Et dans cette procédure, à tester si la touche frappée était bien F1, auquel cas on déclenche l'ouverture de l'aide. Et hop, comme qui rigole.

[modifier]