|
Une remarque pertinente ? Une critique impertinente ? Un lynchage en règle ? Une invitation sous les tropiques ? ![]() Ecrivez-moi ! |
![]() |
|||
|
Conçu et enseigné tel qu'en lui même, avec pertes, fracas et
humour de qualité supérieure par Christophe Darmangeat dans le M2 PISE du Master SSAMECI (Université Paris 7) |
||||
|
Partie 5
D'autres contrôles
Nous pouvons maintenant reprendre le cours de nos pensées
et nous livrer à notre activité favorite : farfouiller dans la boîte à
outils pour en sortir tous les jolis jouets qu'elle contient.
1. La classe Textbox La Textbox, c'est par
définition la zone de prédilection pour que l'utilisateur puisse
saisir des informations. Il n'y a en fait pas grand chose à en dire,
sinon que la Textbox partage avec les autre classes la plupart des
propriétés standard dont nous avons déjà parlé à plusieurs reprises.
Un détail qui a toutefois son importance : la propriété Text d'une
Textbox désigne ce qui se trouve à l'intérieur de la Textbox.
Autrement dit, ce qu'aura saisi l'utilisateur. Par conséquent, nous
pouvons en déduire que tout ce que saisit l'utilisateur via une
Textbox, même lorsqu'il s'agit de nombres, est traité par VB comme une
chaîne de caractères. Naturellement, dans certaines circonstances, des
conversions vont s'imposer...
Je mentionne toutefois quelques propriétés typiques
de la classe Textbox, qui valent le coup d'être signalées :
Tout ceci est plus que suffisant pour que vous vous
dérouilliez les neurones avec quelques exercices :
2. La classe Richtextbox Il s'agit d'une classe fille
de la classe Textbox, qui hérite donc de toutes ses propriétés... tout en
possédant quelques attributs supplémentaires. Et pas des moindres,
puisque les contrôles RichTextBox, sont pour leur part capables de gérer
un contenu au format rtf : c'est-à-dire qu'ils mémorisent de nombreux
attributs de formatage, tels que le gras, l'italique, le souligné,
l'espacement des paragraphes, et autres fanfreluches du même tonneau.
Naturellement, cette bête est directement prédestinée à gérer des
simili-traitements de texte, ou du moins des zones dans lequel l'aspect du
texte est important.
Je ne m'étendrai pas davantage sur cette classe, bien qu'elle possède
pléthore de fonctionnalités, ou plutôt, justement
à cause de cela. Cela nous entraînerait trop longtemps dans des
détails
techniques qui restent d'une importance mineure quant aux mécanismes
essentiels du langage. Et si un jour vous avez besoin d'utiliser une
RichTextBox, vous
trouverez toutes les informations utiles dans la doc.
Alors zou, au suivant.
3. La classe Checkbox La Checkbox, c'est cette charmante petite case carrée que vous
connaissez bien :
Passons rapidement sur les propriétés que les Checkbox partagent
avec la plupart des autres classes, pour en venir à celle qui nous intéresse
au premier chef : celle qui nous permet de savoir si une Checkbox est
cochée
ou non (si nous l'utilisons en lecture), ou de faire en sorte que Checkbox
soit cochée ou non (si nous l'utilisons en écriture). Il s'agit de
Checked : propriété booléenne, qui vaut naturellement True lorsque la
case est cochée et False lorsqu'elle ne l'est pas.
Là où les choses se compliquent un peu, c'est que dans certains cas, on
souhaite pouvoir disposer d'une troisième possibilité : la case "à moitié
cochée", indiquant généralement que certains sous-élements correspondant à
la Checkbox sont actifs, et d'autres non :
Pour pouvoir gérer cette situation difficile, il nous faut avoir
recours à deux autres propriétés supplémentaires :
Les Checkbox sont parfois rassemblées dans un conteneur, qui les présente comme faisant partie d'un même groupe. Cette présentation est purement décorative : elle ne remet jamais en cause le fonctionnement de la Checkbox, toujours individuel et indépendant de ses congénères. Il nous faut enfin mentionner le principal événement
associé aux CheckBox : il s'agit de CheckChanged, qui est déclenché
chaque fois que la
case est cochée ou décochée.
On remarquera la différence subtile, mais réelle, entre les événements CheckChanged et Click, appliqués à une Checkbox. Click ne se produira qu'en cas d'action sur la case via la souris. CheckChanged, en revanche, se produira en cas de clic de souris, mais aussi si une ligne de code a modifié l'état de la case. Ou en cas de changement d'état de la case causé par une action au clavier. Il faut donc réfléchir, avant de choisir l'événement que l'on souhaite gérer, si l'on souhaite réagir ou non à un changement de l'état de la case provoqué par autre chose qu'un clic de souris - si l'application est susceptible de contenir cette autre chose, bien sûr. 4. Les classes Radiobutton, GroupBox et Panel Trois d'un coup, vous vous rendez compte ? Mais ce ne sont pas les plus
pénibles. Voilà tout de suite une illustration de notre propos :
![]() Le RadioButton, dans sa forme classique, n'est
donc autre que la célèbre petite case ronde. Par définition, cette case ne fonctionne qu'en
groupe, conjointement avec d'autres, puisque par principe, une seule des
cases d'un même groupe peut être cochée à la fois. Dit autrement, cocher
une case d'un groupe décoche automatiquement les autres cases du groupe.
Ce groupe est défini par ce qu'on appelle un conteneur, qui peut au
choix être un objet de la classe GroupBox ou Panel. La différence
entre les deux n'est pas furieuse ; disons simplement qu'un Panel,
99 fois sur
100, c'est un conteneur sans texte et sans bordure, donc invisible.
Un RadioButton appartient
donc au même groupe qu'un autre Radiobutton s'il
est placé dans le même conteneur (généralement, un GroupBox).
Ce simple fait suffit à faire marcher les Radiobutton les uns avec
les autres. Il n'y a pas une seule ligne de code à écrire pour cela.
La propriété la plus utilisée du Radiobutton
est évidemment Checked, propriété booléenne qui renvoie (ou définit) si un bouton
radio est coché ou non.
Lorsqu'une case Checkbox déclenche un événement CheckChanged, on est généralement obligé de procéder à un test pour savoir si la case vient d'être cochée ou décochée. En revanche, s'agissant d'un Radiobutton, un tel test est parfaitement superflu : si celui-ci vient d'être cliqué, autrement dit s'il a déclenché un événement CheckChanged, c'est forcément parce que le RadioButton vient d'être coché. Voilà une remarque de bon sens à ne pas oublier si vous voulez vous épargner des lignes de codes inutiles. Encore une petite chose sur les RadioButton. Ceux-ci peuvent prendre
parfois une drôle de tête, comme dans cet exemple :
![]() Ici, nous avons un poste de radio (c'est de circonstance), où nous
pouvons, via deux boutons, choisir une gamme de fréquences ou une autre.
Sur l'image ci-dessus, c'est la FM qui est enclenchée.
Eh bien, ce look un peu inattendu est obtenu simplement en remplaçant
le GroupBox par un Panel (invisible, par définition), et en réglant la
propriété Appearance de nos RadioButton à Button au lieu de Normal.
Bon, si on se faisait un petit exo ?
|
|||