Cours Visual Basic N°3
Aspects du code Visual Basic

On approfondira ici certains aspects déjà abordés précédemment.

Pour mémoire, je rappelle que tout langage de programmation se ramène au bout du compte à la combinaison des quatre opérations suivantes :

• les opérations d’entrées – sorties
• la gestion de variables
• les tests
• les boucles

En ce qui concerne les opérations d’entrée sortie, c’est-à-dire tout ce qui relève du dialogue entre l’utilisateur et la machine, on a longuement vu les particularités d’un langage événementiel dans ce domaine. Et finalement, la plupart des choses que l’on a épluchées précédemment relevaient de cette catégorie. Conclusion, il ne nous reste que trois catégories d’instructions à examiner, plus quelques trucs que j’ai mis dans ce chapitre faute de me décider à les caser ailleurs.

La gestion de variables

1 Types de variables

En fait, nous avons un peu commencé à en faire sans le dire. A priori, Visual Basic n’oblige pas à déclarer une variable avant de s’en servir (il est toujours possible de l’obliger, par une option adéquate). Le seul problème est qu’en l’absence de déclaration, une variable va être automatiquement créée par VB dans le type le plus " souple ", autrement dit le plus gourmand en mémoire. Donc, si dans une petite application, déclarer les variables n’a pas forcément un intérêt majeur, dans un véritable projet utilisant beaucoup de variables, ne pas déclarer ses variables peut conduire à un remplissage exagéré de mémoire, donc à un ralentissement notable de l’exécution. Ajoutons que les variables indicées (tableaux) et les variables publiques (globales) doivent impérativement être déclarées quel que soit le cas de figure.

Les types de variables sont peu ou prou ceux du C (et de n’importe quel autre langage), à savoir :

Type	Contenu
Boolean	true – false
Byte	de 0 à 255
Integer	de –32 768 à 32 767
Long	de –2 à +2 milliards environ
Single	virgule flottante simple précision
Double	virgule flottante double précision
Currency	entier virgule fixe
String	jusqu’à 65000 caractères

Il reste un type particulier de variable : c’est le type Variant>. Comme M.Jourdain, vous avez jusqu’ici fait du Variant> sans le savoir, puisque c’est le type par défaut lorsqu’on ne déclare pas explicitement une variable. Avantage du Variant> : il peut stocker n’importe quel type de données. Inconvénient : il prend énormément de place et ralentit l’exécution.

2 Tester le type d’une variable

Il peut arriver qu’au cours d’un programme, vous ayez besoin de savoir quel type de données est contenu par une variable de type Variant. Dans ce cas, VB met à votre disposition une série de mots-clés pouvant donner

If Tampon = vbEmpty ou If Tampon <> vbIntegeretc.

Vous trouverez la liste de ces vbBidule> dans l’Aide. Alors, de deux choses l’une : ou le type est satisfaisant : on peut ensuite employer cette variable Tampon comme prévu, ou basculer sa valeur dans une variable déclarée dans le type approprié. Dans le cas contraire, on envoie un message à l’utilisateur et on lui fait recommencer la saisie.

3 Portée des variables et déclarations

On a déjà un peu abordé ce problème au cours des exercices, mais voilà enfin l’exposé systématique que vous attendiez tous en haletant. Fermez la bouche et " écoutez moi bien, c’est un sujet d’examen ", comme disait un célèbre militaire.

L’existence d’une variable peut se dérouler sur trois niveaux :

• Procédure : cela veut dire que dès que l’on quitte la procédure en question, la variable disparaît, et son contenu avec elle.
• Form : la variable est disponible pour toutes les procédures de la Form , mais pas pour les procédures se situant sur une autre Form
• Globale : la variable est disponible et sa valeur est conservée pour toutes les procédures de l’application, quel que soit leur emplacement.

Naturellement, est-il besoin de le préciser, il ne faut pas raisonner en termes d’artillerie lourde, et déclarer toutes les variables comme globales, en se disant que comme ça, on est blindé : car ce blindage, par l’excès de place mémoire, ralentira votre application, au besoin considérablement. Il faut donc pour chaque variable se demander à quel niveau on en a besoin, et faire les déclarations en fonction.

Pour déclarer une variable au niveau procédure : à l’intérieur de la procédure,

Dim NomVariable as Type

Pour déclarer une variable au niveau Form : tout en haut de la Form, à l’extérieur des procédures,

Dim NomVariable as Type (non, ce n’est pas une erreur, c’est bien la même chose)

Pour déclarer une variable globale : Il faut d’abord créer un module. Un module est un type de feuille destiné uniquement à recevoir du code, et qui n’a donc pas, contrairement aux Form, d’apparence graphique. C’est dans un module qu’on écrit la procédure principale, lorsqu’on en veut une, et qui de là pilote les différentes Form, elles mêmes donnant accès aux procédures liés aux objets qu’elles contiennent. Sur ce module, donc, on écrit : Public NomVariable as Type A noter que le mot-clé Dim peut être indifféremment remplacé par Private, pour plus de clarté, paraît-il ( ?)

4 Variables indicées

On appelle aussi cela des tableaux. Ce peuvent être des tableaux de nombres, de chaînes, de booléens, bref, de tout ce qu’on veut. Quant on crée un tableau, soit on sait d’avance combien d’éléments il va englober, soit on veut qu’il soit élastique (mais cela se paye bien sûr par une perte de rapidité à l’exécution).

Pour créer un tableau de 12 entiers, on écrira :

Dim MonTableau(11) As Integer

Eh oui, le premier élément porte le numéro zéro. Ah ! Ah !

Pour créer un tableau élastique (pour faire plus classe, ne dites pas " élastique ", dites " dynamique "), on écrira :

Dim MonTableau() As Integer

Ensuite, dès qu’on veut en fixer la taille, on écrit dans le code :

Redim MonTableau(11)

En résumé, aucun problème spécifique ici que vous n’ayez déjà abordé sur un langage précédent (le C, par exemple, à tout hasard)

Les tests

Là aussi, on retombe dans les grands classiques du genre ; le fait que VB soit un langage objet n’a aucune espèce d’influence. On retrouve donc le célebrissime :

If condition then Instructions Else Instructions Endif

Il y a bien sûr quelques possibilités supplémentaires, comme le Elseif (que je déconseille généralement, chacun ses névroses) ou le Case (qui peut parfois être utile).

Les boucles

Là non plus, rien à signaler. On aura donc un grand standard, le :

While condition Instructions Wend Et le : For i = x to y step z Instructions Next i

Je ne m’attarde pas, puisque tout ça, je sais que vous jonglez avec comme qui rigole.

Gérer les erreurs

On sait que dans une application digne de ce nom, même lorsqu’une erreur se produit (fichier introuvable, mauvaise saisie au clavier, etc.) cette erreur ne donne pas lieu à un plantage inopiné du programme, mais qu’elle est gérée par ce programme. Cette brève section est donc consacrée aux erreurs à l’exécution, et au moyen de les prévoir (à défaut de pouvoir les empêcher).

Un objet à tout faire a été prévu : c’est Err, qui possède notamment comme propriétés :

Number le code de cette erreur, vous permettant de l’identifier
Description un rapide bla-bla sur la nature de l’erreur
Source qui vous indique l’objet à l’origine de l’erreur

Le truc consiste, au début d’une procédure susceptible d’engendrer des erreurs, à taper la ligne suivante :

On Error GoTo Etiquette

Une étiquette, c’est un sous-Titre à l’intérieur d’une procédure, se terminant par le signe " : ".

Oui, je sais, c’est une pure horreur que d’obliger les gens à mettre des GoTo dans un joli programme structuré. Mais que voulez-vous, ici, Microsoft ne nous a pas laissé le choix. L’idée est donc que si une erreur, quelle qu’elle soit, survient au cours de cette procédure, au lieu de sa planter bêtement, l’application ira gentiment rechercher l’étiquette que vous avez désignée, et exécutera son code.

Exemple :

Public Sub Totoche() On Error GoTo Oops
Tata = 12 / 0
Msgbox Tata
Exit Sub Oops: Msgbox(" Diviser par zéro, c’est pas malin ! ") End Sub

Bien sûr, ici, notre gestionnaire d’erreurs est vraiment a minima. On peut faire quelque chose de beaucoup plus fin en y testant la valeur Err.Number, et en réagissant différemment selon le code (donc le type) de l’erreur qui est survenue.

Appeler une procédure par du code

Jusqu’ici, toutes les procédures que nous avons utilisées étaient des procédures événements : leur nom était régi par des règles strictes, qui spécifiaient le déclenchement de leur exécution. Mais comme tout langage, le VB vous permet de créer des procédures traditionnelles, baptisées selon votre bon vouloir. Leur exécution sera déclenchée non par une action de l’utilisateur, mais par une instruction de votre programme. C’est donc l’équivalent VB du GOSUB cher à vos cœurs.

Je rappelle de tels appels peuvent comporter des paramètres, ou non, cela ne change rien de fondamental à l’affaire.

Un cas extrêmement classique d’utilisation de cette technique, c’est celui de l’initialisation d’une Form. Pour que cette Form soit propre, on veut que toutes les zones de textes soient vierges. Pour peu qu’on ait besoin de procéder à l’initialisation à plusieurs moments différents de notre application, au lieu de répéter à chaque fois les mêmes codes, on va créer une procédure Init() qui comportera les lignes de code nécessaires :

Private Sub Init() Nom.Text = " "
Prénom.Text = " "
Etc. End Sub

Pour appeler cette procédure, il suffira ensuite de passer l’instruction suivante :

Call Init()

Et le tour est joué.

Attention toutefois aux portées des procédures. Une procédure Private n’est disponible que si l’appel se situe dans la Form qui la contient. Pour qu’une procédure puisse être appelée de n’importe quelle Form, il faut qu’elle porte comme nom Public.

Procédure de démarrage

Lors du lancement de l’application, VB a besoin de savoir quelle procédure (ou quelle Form) est la procédure (la Form) par défaut. Si vous ne touchez à rien, il s’agit toujours de la première Form qui existait dans le projet.

Si vous souhaitez changer de Form par défaut, ou si vous souhaitez lancer le projet par une procédure principale indépendante de toute Form, ça se passe dans le menu Projet – Propriétés. Vous y choisissez de lancer l’application :

• en définissant la Form par défaut
• ou par une procédure principale, qui devra se obligatoirement se trouver dans un module et s’appeler Sub Main()

With… End With

Petite combine bien pratique pour éviter de répéter 15 fois la même chose :

Plutôt que d’écrire :

MyObject.Height = 100
MyObject.Caption = "Bonjour à tous"
Etc.
MyObject.Font.Color = Red
MyObject.Font.Bold = True
Etc.

On écrira :

With MyObject .Height = 100
.Caption = "Bonjour à tous"
etc.
With .Font .Color = Red
.Bold = True
etc. End With End With

Dans cet exemple mal choisi, il semble qu’on ne gagne pas tellement de place. Mais réfléchissez bien, en fait, si, dès que les et caetera sont un peu nombreux.

Un contrôle bien spécial : 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 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 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 déroule, même si l’utilisateur ne fait rien du tout.

Le contrôle Timer, toujours invisible, va générer des " tops " à une cadence choisie par le programmeur (propriété Interval, exprimée en millisecondes), pour déclencher la procédure Timer1_Timer(). Le programmeur pourra donc mettre dans cette procédure tout ce qui doit se passer sans que l’utilisateur ne fasse quoi que ce soit.

Le 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.)