 |
Rappel : Ce cours est enseigné dans la |
||||||||||||||||||||||||||
|
Ce chapitre fourre-tout a pour but de faire un tour relativement complet des
propriétés et des événements les plus utiles pour les différents objets.
Bien entendu, vous avez déjà eu l’occasion de croiser un certain nombre de
ces choses, mais là, vous allez repartir avec de quoi faire votre petit
marché en toute quiétude.
1.1 Un contrôle particulier : le Timer
Il s’agit du petit chronomètre situé dans la barre de contrôles. Ce contrôle joue un
rôle fondamental et indispensable : c’est lui
qui va permettre d’effectuer des traitements, à intervalles fixés
d'avance, indépendamment des actions effectuées par l’utilisateur.
Jusqu’à présent, en effet, le code ne s’exécutait (si l’on met de côté le
Form_Load
et une éventuelle procédure principale située dans un module) qu’au cas où
l’utilisateur faisait quelque chose : saisie au clavier, mouvement ou clic
de souris, etc. Or, on peut tout à fait avoir besoin, dans certaines
applications, que le code se mette en route, même si l’utilisateur ne fait
rien du tout.
Le contrôle Timer, graphiquement toujours
invisible, va générer des événements,
des "tops", à une cadence choisie par le programmeur, qui déclencheront
la procédure NomDuTimer_Timer(). Le
programmeur pourra donc mettre dans cette procédure tout ce qui doit se
passer indépendamment de ce que fera – ou ne fera pas - l’utilisateur.
Un Timer est très utile dans certains
jeux, soit qu’on ait besoin de chronométrer quelque chose, soit qu’on ait
besoin de provoquer certains événements à intervalles réguliers (un
déplacement d’un bidule, la survenue d’un événement du jeu tiré au hasard,
etc.)
La propriété essentielle d'un Timer est
Interval. C'est elle qui fixe
l'intervalle entre chaque top, exprimé en millisecondes).
1.2 L'objet "Application" : App
Ce jour est à marquer d'une pierre blanche, car voici
notre première rencontre avec un objet qui n'est pas un contrôle, et qui
ne possède donc aucune existence sous forme de représentation graphique.
Loin des yeux, mais pas loin du cœur, voici l'objet
App, qui n'est autre que l'ensemble de
votre application elle-même, en personne. App,
comme tout objet, possède un certain nombre de propriétés. L’une d’entre
elles est particulièrement utile : il s'agit de la propriété
Path, accessible uniquement en lecture, et qui
indique quel est le chemin d’accès de l'exécutable.
Ceci se révèle particulièrement utile quand on a besoin d'aller chercher d'autres
documents (fichiers textes, images à charger, etc.) dans une application.
On ne sait jamais a priori comment s'appelle le répertoire dans lequel
votre application a été installée sur d'autres machines que la vôtre.
Grâce à l'objet App, et à sa propriété
Path, on va donc pouvoir récupérer
l'emplacement de l'exécutable, et de là, pointer le chemin conduisant au
fichier que l'on veut manipuler.
Donc, en résumé, on peut utiliser cette propriété pour
désigner un fichier par référence relative au répertoire dans lequel a été
installé l'application, quel que soit le répertoire en question.
Admettons par exemple
que vous ayez besoin d'aller désigner un fichier au cours d'un programme,
parmi une dizaine disponibles (genre mois01.txt, mois02.txt, etc.). Vous
mettez donc le nom du fichier à aller chercher dans une variable nommée
Fic. Mais comment préciser à l'ordinateur le chemin menant à ce fichier ?
Ce chemin sera a priori différent selon la manière dont votre application
aura été installée sur chaque machine. La parade consistera donc :
Illustration :
' La variable Fic stocke le nom du fichier à ouvrir
Chemin = App.Path If Right(Chemin, 1) <> "\" Then Chemin = Chemin & "\" EndIf Complet = Chemin & Fic MsgBox "L'emplacement complet est : " & Complet
On n’examinera ici que certaines des propriétés les plus courantes, celles
que l’on retrouve pour la majorité, sinon la totalité, des contrôles. Bien
entendu, vous avez déjà expérimenté un certain nombre de ces choses, et il
ne s'agit là que d'un petit complément..
2.1 Localisation des contrôles
Tout contrôle placé sur une Form possède deux propriétés qui régissent
son emplacement :
Comme vous le savez aussi, il y a également deux propriétés qui règlent la taille du contrôle.
Ce sont :
Avec ces quatre propriétés, on règle donc et la taille et l’emplacement de tout
contrôle, et on peut faire des choses graphiquement très joulies. CQFD.
2.2 Activation des contrôles
La plupart des contrôles possèdent les propriétés suivantes :
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 :
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 :
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 :
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 :
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.
Là, on peut vraiment s’amuser. Et par les temps qui courent, il ne faut pas rater de
si belles occasions.
Prenons tout de suite un exemple, qui serait de permettre à un utilisateur
d’effectuer un cliquer-glisser sur un bouton de commande, afin de le
déplacer sur la Form.
Regardons ce qui se passe alors :
Une remarque fondamentale : on doit remarquer que le
cliquer-glisser ne provoque en aucun cas de lui-même un déplacement de
l’objet de départ. Si l’on veut qu’un tel déplacement survienne, on doit le
programmer expressément par le code adéquat.
La gestion du cliquer glisser n’est pas difficile, à condition de suivre
méthodiquement les étapes.
Résumons-nous. Un cliquer-glisser représente donc
une série de trois types d’événements potentiels, qu'il va falloir gérer
pour chacun des objets susceptibles de les recevoir...
Avec un peu d’habitude et un minimum de
rigueur, on peut parvenir à de très jolis résultats.
Dames est un exemple de Drag & Drop où l'on donne l'illusion à l'utilisateur
qu'il déplace un objet avec sa souris. Mais rappelez vous, ce n'est
qu'une illusion ! Celle-ci est produite par le fait que l'icône de
déplacement est la copie conforme de l'objet... Je vous laisse méditer
là-dessus. Quant à
Manège, il emploie un petit truc algorithmique un brin finaud (mais rien de
vraiment méchant).
|
