Evénements

On va dans cette partie aborder des événements jusque là injustement dédaignés.
Je passe rapidement sur le Click et le DblClick, qui n’ont plus de secrets pour vous. Toutefois, c'est le moment de préciser un détail important : un contrôle ne peut pas à la fois posséder une procédure liée au click (simple) et au double click, car un des deux événements intercepte toujours l'autre. clic ou double clic, le concepteur d'interface doit donc choisir entre les deux !
Plus intéressants, car moins connus, en voici quelques autres :
3.1 Evénements Focus
Le focus est le fait, pour un contrôle, d’être celui qui est actuellement désigné par la tabulation (un petit liseré en pointillé apparaît autour d’un objet lorsqu’il a le focus, ou dans le cas des zones de texte, le curseur clignote à l'intérieur). Deux événements sont liés à la réception ou à la perte du focus :
Gotfocus : quand l’objet reçoit le focus
Lostfocus : quand l’objet perd le focus
J’en profite négligemment au passage pour signaler qu’une instruction permet de forcer le passage du focus à tel ou tel contrôle. Il s’agit de la méthode Setfocus. Ainsi, la ligne de code :
TrucMuche.Setfocus
envoie de gré ou de force le focus sur le contrôle TrucMuche.
3.2 Evénements clavier
On peut être amené, dans une application, à vouloir "guetter" la frappe de touches du clavier par l’utilisateur. Ceci recouvre grosse moto deux cas :
On veut gérer la saisie caractère par caractère dans un contrôle Textbox ou ComboBox. Ceci pour contrôler au fur et à mesure la validité des caractères frappés (éliminer les chiffres, par exemple…) ou convertir les caractères au fur et à mesure les caractères frappés (les convertir automatiquement en minuscules ou en majuscules, par exemple…). Dans ce cas, on pourra gérer les événements KeyPress KeyUp ou Keydown (voir plus loin pour le choix) au contrôle concerné.
On souhaite affecter, indépendamment de tout problème de saisie dans un contrôle, certaines actions à certaines touches du clavier. Typiquement, affecter les touches de fonctions : F1 pour ouvrir l'aide, etc. Ici, c’est à la Form que l’événement clavier devra être associé. Mais cela ne fonctionnera que si la propriété KeyPreview de la Form possède la valeur True. Dans ce cas, la Form reçoit ces événements avant les contrôles qu'elle contient.
La différence fondamentale entre KeyPress d’une part, et Keydown et Keyup d’autre part, c’est que KeyPress considère quel caractère a été frappé (le résultat logiciel de la frappe), alors que Keydown et Keyup considèrent l’état physique du clavier.
Par conséquent : KeyPress ne reconnaît pas les frappes ne produisant pas directement un caractère, comme les touches de fonction, les touches de modification, les touches de navigation et toutes les combinaisons de ces touches avec les modificateurs du clavier. En revanche, Keydown et Keyup gèrent parfaitement tout cela.
Autre différence, KeyPress interprète la majuscule et la minuscule de chaque caractère comme des codes de touche distincts et, par conséquent, comme deux caractères différents. KeyDown et KeyUp, quant à eux, interprètent la majuscule et la minuscule de chaque caractère au moyen de deux arguments : keycode, qui indique la touche physique (A et a étant alors équivalents) et shift, qui indique l'état de shift + key et qui renvoie en conséquence soit A, soit a.
Dernière chose sur ce chapitre, Keydown détecte le moment où une touche est enfoncée, KeyUp celui où elle est relâchée.
La gestion fine des événements clavier restant une chose relativement pénible en Visual Basic, nous passons rapidement à quelque chose de beaucoup plus répandu…
3.3 Evénements souris
MouseDown et MouseUp sont deux événements détectant respectivement le fait qu’un bouton de la souris a été enfoncé ou relâché au dessus d’un objet.
Un aspect fondamental de ces événements, c'est que la procédure qui leur est associée possède un certain nombre de paramètres. C'était déjà le cas avec les événements claviers ci-dessus, mais j'avais alors jeté un voile pudique sur cet aspect. En tout cas, là, avec la souris, on n'y coupera pas. Les paramètres en entrée de toute procédure liée à un événement souris sont là pour vous permettre notamment de récupérer dans cette procédure :
quel bouton de la souris a provoqué l’événement (bouton de gauche, bouton de droite, etc.)
l’état des touches Maj, Ctrl et Alt du clavier. Ceci permet de gérer des combinaisons alambiquées clavier + souris. A réserver uniquement aux émules des interfaces Adobe.
les coordonnées x et y désignant l’endroit où l’événement s’est produit. Et là, gaffe de chez gaffe ! Ces coordonnées sont toujours relatives à l’objet ayant reçu l'événement. Donc ce ne sont les coordonnées par rapport à la Form que si l’objet recevant l’action est bien la Form. Réciproquement, si on gère un MouseDown sur une image, le X et le Y désigneront la position de la souris par rapport à cette image au moment du MouseDown. Si l'on veut en déduire les coordonnées de la souris par rapport à la Form, il faudra ajouter les coordonnées de l'image dans le Form. Tout le monde suit ?
Quant à l'événement MouseMove, il détecte le déplacement de la souris au-dessus d’un xontrôle. Cet événement possède les mêmes paramètres que les deux événements précédents.
Par ailleurs, il faut signaler en passant qu’en VB, les possibilités de personnaliser l’apparence de la souris sont nombreuses et simples d’utilisation. Chaque contrôle possède ainsi deux propriétés chargées uniquement de gérer cet aspect des choses :
MousePointer: indique quelle tête la souris doit prendre lorsqu’elle survole l’objet, tête, choisie parmi la liste des possibilité standard de Windows.
MouseIcon désigne un fichier image (type *.ico ou *.cur) définissant un pointeur de souris personnalisé.
On peut donc très facilement, en affectant l'une ou l'autre de ces propriétés (pas les deux en même temps, ça n'aurait aucun sens), faire en sorte que le pointeur de la souris change de tête au survol de tel ou tel contrôle. C'est un des petits détails qui donnent à une interface un look professionnel et "fini", et celui-là, comme on le voit, ne coûte vraiment pas cher.
L'enfer du jeu est un exercice un peu plus long, qui a valeur de récapitulatif. Il comporte deux difficultés majeures.
La première est liée à la formule - et à l'algorithme - de calcul. Cet algorithme est posé sous forme d'exercice, et fort heureusement, de corrigé, dans le fabuleux cours d'algorithmique du même auteur.
La deuxième difficulté tient à l'affichage du résultat sous un format dit "de milliers", format séparant les chiffres par groupe de trois pour améliorer la lisibilité. Cet affichage n'ayant pas été prévu par le langage VB, la programmation insère des espaces là où il faut, ce qui constitue une splendide prise de tête