Avec les deux exercices qui précèdent, on constate un alourdissement considérable du code, qui devient redondant pour un certain nombre d'objets.
Cela tient au fait que jusqu'à présent, nous avons toujours considéré que chaque contrôle était un objet complètement indépendant de ses congénères. Cela se manifestait de deux manières :
lors de leur création, nous allions toujours chercher l’objet dans la boîte à outils, en nous abstenant soigneusement de procéder à des copier coller.
par conséquent, chaque objet possédait une propriété Name bien à lui, qui nous permettait de le désigner sans ambiguïté en écrivant le code. Et du coup, chaque objet possédait ses propres procédures événementielles, distinctes de celles liées aux autres objets.
Mais cette stratégie induit lors de certains programmes une lourdeur qui ne vous aura pas échappé. Lorsque plusieurs objets de même type remplissent des tâches voisines, voire semblables (cf. les deux exercices précédents), on se retrouve avec une flopée de procédures événementielles (une par objet, parfois davantage) qui se ressemblent beaucoup, voire qui sont carrément semblables.
La création d’un groupe de contrôles a pour but d’alléger tout ceci. Comment ça marche, me direz-vous ? Eh bien voici.
Lors de la création des contrôles (mettons, une série de quatre cases à cocher), on procède dorénavant par copier-coller, en prenant soin, s'il s'agit de cases d'options, que le collage s’effectue bien au sein du Frame (sinon, elles ne marcheront pas correctement ensemble). A la question "souhaitez-vous créer un groupe de contrôles?", on répond sans réserves par l’affirmative.
Dès lors, les quatre objets ainsi créés seront en fait des membres d’un même groupe. En Français, cela signifie que ces quatre objets porteront le même nom (Name) mais affublé d’un Index qui servira à les identifier individuellement. Tout cela rappelle furieusement les tableaux, hein ? C'est bien normal, puisque c'en est.
Si j’osais une métaphore ailée (mais non filée), je dirais que le groupe est au contrôle ce que le tableau est à la variable simple. Limpide, non ? J'ajoute pour conclure que Index est une propriété – c'est logique – de tout élément d'un groupe de contrôles, définissant son indice (propriété à ne surtout pas confondre avec TabIndex, qui définit son ordre dans la tabulation, ce qui n'a rien à voir avec la choucroute).
Donc, résumons nous.
Si on a créé un groupe de 4 contrôles de classe Checkbox le nom par défaut de ce groupe sera Check1. Rebaptisons-le CaseCarrée pour plus de clarté. On aura alors CaseCarrée(0), car l'Index commence à zéro comme pour tout tableau qui se respecte, CaseCarrée(1), CaseCarrée(2) et CaseCarrée(3).
Si on a un traitement à effectuer sur les quatre cases, on pourra dorénavant écrire une boucle, par exemple pour décocher tout ça :
For i = 0 to 3
CaseCarrée(i).Value = 0
Next i
Déjà, on se marre bien. Mais c’est encore plus rigolo quand on crée la procédure associée à ce groupe. Cela produit un intitulé du genre :
Private Sub CaseCarrée_Click (Index as Integer)
End Sub
Eh oui, vous avez bien vu. Cela signifie que dorénavant, pour un événement donné, il n’y a plus qu’une seule procédure pour l’ensemble des contrôles du groupe !
Quant à la variable Index, dont vous voyez que Visual Basic la crée automatiquement en tant que paramètre en entrée de cette procédure, elle contient à chaque exécution de la procédure, l'indice de l'élément du groupe qui vient de déclencher l'événement.
Ainsi par exemple, si au sein de cette procédure, on a besoin de savoir quelle case a été cliquée, il suffit de tester la variable Index, qui, en l'occurrence, vous l’aurez deviné, peut valoir de zéro à trois.
A noter qu'Index est ici une simple variable, à ne pas confondre avec la propriété Index des éléments des groupes de contrôles. Donc, si ce nom de variable vous semble trop lourdingue, rien ne vous interdit de le modifier.
Formulons tout cela d'une traite : Index est le nom par défaut du paramètre en entrée pour la procédure événementielle, paramètre qui prend à chaque exécution la valeur de la propriété Index du membre du groupe qui a déclenché cette exécution.
Avec tout cela, certains programmes vont pouvoir s'alléger considérablement. Moralité, en VB, c’est comme pour tout le reste, pour pouvoir être fainéants, devenons compétents.
Les exercices liés aux groupes reprennent ceux que l'on vient d'effectuer à propos des cases. Mais à présent, ils doivent bien sûr être programmés très différemment... Les sources présentées ici donnent la solution employant la technique des groupes.
Pour les Options Onéreuses, il y a au moins deux moyens d'éviter une fastidieuse série de tests.
A Table et Cinq à la suite sont deux autres exemples simples du gain de temps que peuvent permettre les groupes.
A signaler que pour le Cavalier Déchaîné (déjà nettement plus difficile), il existe plusieurs astuces (plus ou moins méchantes) pour s'épargner de longs fragments de code répétitifs.
Que voulez-vous, quand on aime les vicieusetés algorithmiques, on ne se refait pas.
Mer 13 Fév - 8:09