Jusqu'à présent, nous avons toujours considéré les contrôles individuellement. Un contrôle, un nom de contrôle, et au moins une ligne de code. Dix contrôles à traiter, au moins dix lignes de code. Cinquante contrôles à traiter, au moins cinquante lignes. Pas moyen d'y couper.

La seule combine qui nous a permis, dans certaines circonstances, de faire une entorse à ce principe, a été de brancher le même événement survenant sur plusieurs contrôles, sur une procédure événementielle unique, via l'instruction Handles. Ceci nous a également permis de manipuler les propriétés du contrôle ayant appelé la procédure, via le paramètre sender.

Ce que nous allons voir à présent, c'est comment on peut généraliser les occasions de traiter les contrôles en série, et plus seulement pièce par pièce.

Dans les versions précédentes de Visual Basic, existait un outil que tout programmeur débutant pouvait maîtriser en quelques coups de cuiller à pot, et qui rendait des services inestimables : les tableaux de contrôles. Cela fonctionnait de la même manière que les tableaux de variables, et cela ouvrait les mêmes possibilités.

Bref, c'était tellement simple, tellement intuitif et tellement efficace que dans la dernière version de VB, à savoir VB.Net, celle-là même que vous êtes en train d'étudier, bande de petits veinards, eh bien les tableaux de contrôles ont tout simplement disparu.

En lieu et place, nous voilà à présent pourvus d'une série d'ustensiles et d'un bric à brac plus ou moins heureux et maniable, dans lequel nous allons devoir piocher tant bien que mal en fonction des circonstances. Au passage, si quelqu'un de chez Microsoft comprend la logique de cette évolution du langage, et qu'il se sent capable de me l'expliquer, qu'il ne se gêne surtout pas. Il a néanmoins intérêt à être sacrément convaincant, parce qu'autant lui dire tout de suite, ce n'est pas gagné.

Bref, exit les tableaux de contrôles, que nous reste-t-il ? Un machin qui s'appelle les collections, machin qui se rapproche furieusement des tableaux de contrôles... sans jamais leur ressembler complètement.

Commençons par dire que par définition, sans même que nous ayons besoin de faire quoi que ce soit pour cela, tout contrôle posé sur une Form devient aussi sec un membre d'une collection, en l'occurrence la collection Controls. C'est-à-dire que ce contrôle devient le membre d'un ensemble, que nous allons traiter comme tel, et sur lequel nous allons pouvoir programmer des boucles. Car il est possible de balayer l'intégralité des membres d'une collection par une boucle, tout comme on peut balayer l'intégralité des éléments d'un tableau. Sauf que tout n'est pas toujours exactement simple dans cette affaire...

La manière la plus évidente de désigner les contrôles dans une collection, va être de se référer à leur indice dans cette collection.

"Faudrait savoir !" Tel est le cri que j'entends déjà sourdre parmi les masses estudiantines opprimées, suite à la lecture de la phrase précédente. En effet, il y a à peine quelques paragraphes de cela, j'expliquais que les tableaux de contrôles n'existaient plus en VB.Net. Et là, je me ramène avec des collections où les contrôles  sont désignés par des indices... Alors, incompétence manifeste ? Absence totale de conscience professionnelle ? Alzheimer précoce ? Schizophrénie caractérisée ?

Rien de tout cela. Dans la collection Controls, les contrôles possèdent certes un indice, et cela constitue un point commun avec les tableaux. Mais il reste tout de même de sérieuses différences :

En l'occurrence, pour balayer les contrôles d'une Form, on pourra donc faire une boucle sur l'indice de ces contrôles dans la collection Controls. Le premier indice est par définition 0. Quant au dernier, nous pouvons le déduire de la propriété Controls.Count, qui renvoie le nombre de contrôles dans la collection Controls. Dans la forme la plus étendue du code, il faudra, pour accéder à l'indice, passer par la propriété Item. Le code permettant par exemple de rendre visible tous les contrôles d'une Form sera donc :

Le plupart des collections - car je le rappelle, il existe bien d'autres collections que la collection Controls - autorisent toutefois l'omission de la propriétés Item. On peut donc souvent écrire en abrégé, et pour le même résultat :

Bon. Certes. Mais il y a d'autres moyens de parcourir une collection...

Cette structure de boucle permet spécifiquement de parcourir une série de contrôles. Tout repose sur le fait que la variable qui va servir de compteur à la boucle n'est ici plus un nombre, comme dans toutes les boucles For ... Next que nous avons écrites jusque là, mais que cette variable représente directement un contrôle. Autrement dit, la boucle va se servir d'une variable qui va désigner successivement plusieurs contrôles. Donc d'une variable de type Control.

Le code précédent pourra ici être réécrit comme :

La variable Truc étant de type Control, sa déclaration aura auparavant été :

En soi, et sur l'exemple choisi, cette technique n'apporte rien de spécial par rapport à la précédente. Mais comme on le verra plus loin, il y a des circonstances où elle révèlera des avantages notables.

Il faut noter que dans le cas où la collection parcourue ne comporte que des contrôles de la même classe, on peut tout à fait déclarer la variable objet directement comme un membre de la classe en question. Ainsi, au lieu d'avoir un :

On pourrait très bien déclarer Truc comme Label :

ou comme bouton :

...etc.

Encore une fois, cela suppose que tous les contrôles de la collection soient bien de la classe spécifiée. Dans le cas contraire, il y aura forcément une erreur à l'exécution...

Avançant à l'aveuglette parmi les membres divers et variés de la collection Controls de la Form (ou parmi toute autre sous-collection, telle celle d'un contrôle conteneur), nous pourrions bien avoir parfois besoin d'un moyen pour identifier ne serait-ce que la classe des ces différents membres. C'est possible grâce à l'instruction

Par exemple, le code suivant met à blanc toutes les zones de textes (et uniquement elles) d'une Form :

Jouons donc un peu...

Il y a la collection Controls, créée et gérée automatiquement par VB, avec toutes les limites que nous venons de découvrir. Il y a les collections que constituent automatiquement les contrôles dits "conteneurs" (tels que GroupBox ou Panel). Mais il existe aussi la possibilité de créer ses propres collections par du code. Bien que cela soit un peu fastidieux, c'est parfois le seul moyen de gérer correctement certains problèmes.

La première chose à faire sera de déclarer la collection, en lui donnant un nom (exactement comme on déclare une variable, ou un tableau). Par exemple :

Ensuite, il va falloir entrer dans cette collection, un par un, tous les éléments qui devront en faire partie, via la méthode Add. Par exemple :

Disons tout de suite qu'on peut, de même, retirer un contrôle d'une collection par la méthode Remove :

Arrivés à ce stade, nous savons donc gérer comme bon nous semble les membres d'une collection. Cela nous permet notamment de pouvoir procéder sans problèmes à des balayages systématiques (par exemple pour initialiser les valeurs de toute une série de contrôles, pour les rendre visibles ou invisibles, etc.). Cela nous permet également de désigner chaque contrôle membre de notre collection par son indice dans cette collection, exactement comme nous le faisions avec la collection prédéfinie Controls. Enfin... presque !

Passons. Un autre avantage considérable de disposer de tableaux de contrôles, était de pouvoir traiter un même événement survenant aux différents membres du tableau avec une seule procédure. Dans l'état actuel de nos connaissances, c'est certes possible, via l'instruction Handles qui figure dans les titres des procédures : il suffit de faire suivre cette instruction Handles de la liste complète des membres de la collection. C'est d'ailleurs cette technique que nous avons déjà eu l'occasion d'utiliser dans plusieurs exercices, sans même pour autant avoir créé de collection. Toutefois, cette combine a des limites :

La parade à ces problèmes tient dans la possibilité de rattacher par du code, donc en cours d'exécution, tel événement survenant à tel contrôle, à telle procédure existante. C'est le sens de l'instruction AddHandler, qui donnera par exemple :

Je fais remarquer qu'il y a une virgule après l'événement, et deux "d" à AddressOf. Sinon, bing, VB ne comprend rien. Dans cet exemple, MiseAJour est le nom de la procédure sur laquelle nous programmons le "branchement" de l'événement Button2.Click.

Se pose la question de savoir où doit figurer cette instruction Addhandler. Cela va sans dire (mais cela va mieux en le disant), elle doit obligatoirement être située dans une procédure qui sera exécutée avant l'événement concerné par Addhandler. Si j'utilise Addhandler pour que le clic sur Bouton2 déclenche la procédure MiseaJour, il faut obligatoirement que ce Addhandler soit exécuté avant que l'utilisateur ait pu cliquer sur Bouton2. Faute de quoi la procédure MiseaJour ne sera pas branchée au clic sur Bouton2 et l'utilisateur aura beau massacrer le bouton de sa souris, il ne se passera rien du tout.

On peut donc dire que l'instruction Addhandler devra figurer dans une procédure qui, du point de vue de la chronologie de l'exécution de l'application, se situera :

Nous sommes presque au bout de nos peines. Nous savons à présent :

Il ne nous reste plus qu'un seul souci, mais de taille. Imaginons que nous ayons 125 boutons sur notre Form, sur lequel un clic mène infailliblement à une procédure unique. Comment faire pour récupérer, au sein de cette procédure, le bouton précis qui a provoqué l'événement (ce qui est souvent indispensable) ? Nous disposons certes du paramètre Sender, que nous avons déjà utilisé lors d'exercices précédents. Sender est une variable objet, qui contiendra le nom du contrôle ayant déclenché l'événement.

Il y a alors de fortes chances pour que nous ayons besoin de savoir à quel indice dans la collection correspond le contrôle désigné par cette variable Sender. Pour cela, nous pouvons utiliser la méthode IndexOf, qui renvoie l'indice de n'importe quel contrôle au sein de n'importe quelle collection... enfin, presque. J'y reviens dans un instant. Ainsi, imaginons que nous ayons créé un Panel comprenant une série de 100 boutons, pour lesquels une boucle a habilement renvoyé l'événement Click vers une procédure Yaclic.  Supposons enfin que nous souhaitions afficher en titre de la Form l'indice du bouton sur lequel l'utilisateur vient de cliquer. La procédure Yaclic aurait alors la tête suivante :

Cette technique, simple et efficace, ne fonctionnera toutefois pas au sein des collections que nous aurons créées et remplies par du code, les collections créées par le programmeur ignorant la méthode IndexOf ! Pour celles-ci, il faudra avoir recours à une voie détournée : programmer une boucle qui compare, par exemple, la propriété Name de chaque membre de la collection Macollec avec celui du sender, sur le modèle suivant :

En conclusion : VB.Net permet de faire tout ce que nous permettaient les tableaux de contrôles des versions précédentes de VB, mais souvent au prix d'un code plus compliqué. Et par-dessus le marché, au lieu d'établir une règle simple fonctionnant dans toutes les situations, les gars de chez Microsoft se sont amusés à multiplier les exceptions. Comme quoi, les Shadoks ont incontestablement inspiré Bill Gates lorsqu'ils proclamaient solennellement : "En essayant continuellement, on finit par réussir. Donc : plus ça rate, plus on a de chance que ça marche"
 

J'y ai fait rapidement allusion un peu plus haut, alors autant ne pas vous laisser dans les ténèbres de l'ignorance. D'autant qu'une fois que vous aurez appris cette technique, vous aurez à votre disposition un ensemble de mécanismes qui vous permettra de faire face à bien des situations.

Alors voilà, l'affaire est toute bête, et tient en peu de mots : il est possible de créer et de détruire des contrôles en cours d'exécution, via les instructions appropriées.

Créer un nouveau contrôle par du code n'est pas plus compliqué que créer une nouvelle variable : on retrouve le mot-clé Dim, et la spécification de la classe du contrôle. Sans omettre le constructeur New, indispensable dès que la déclaration porte sur autre chose qu'un type simple. On aura ainsi une ligne du genre :

Où Toto sera la propriété Name du nouveau bouton créé. Mais à ce stade, nous n'avons créé qu'un bouton désincarné, virtuel, si j'ose dire, et qui n'appartient à aucun ensemble de notre application. Si l'on veut par exemple que le nouveau bouton soit visible (et en général, c'est vivement recommandé), il est indispensable de l'incorporer dans la collection Controls de la Form :

Toto est dorénavant un contrôle comme un autre de la Form. Si, pour libérer de l'espace, on veut à un moment où à un autre détruire le contrôle, il suffira de lui appliquer la méthode Dispose.

Le seul détail qui nous reste à régler - mais par rapport à ce qu'on s'est cogné jusque là, ça va être du cake - c'est de savoir comment on va faire pour attribuer automatiquement des noms (des propriétés Name) à toute une série de contrôles créées à la chaîne par du code.

Pour cela, il suffit par exemple de concaténer un nom (mettons, Toto), et un nombre généré par une boucle. De toutes façons, l'essentiel est que les noms soient tous différents : le reste, on s'en fiche un peu, puisqu'on ne se resservira des contrôles qu'en les désignant par leur indice dans la collection dans laquelle nous les aurons rangés.

Voilà, pour résumer, un code qui accomplit les tâches suivantes :

Pour gérer le clic sur ces cases et afficher laquelle a déclenché l'événement, nous retrouverons donc un code déjà vu, sur un mode un brin laborieux (puisque l'emploi d'une collection personnalisée MesCases nous interdit de récupérer directement l'indice via IndexOf). Il va de soi que dans certaines situation, on pourra tout de même optimiser un peu la boucle :

Et voilà. Bon, avec ça, on va pouvoir faire des noeuds très jolis (et très gros) à nos neurones.