Foin de fausse modestie, ce cours poursuit un double objectif :

Visual Basic étant, comme tout langage moderne, richissime en fonctionnalités, il va de soi que les quelques pages qui suivent ne remplaceront ni une consultation intelligente de l’aide du logiciel, ni le recours à des ouvrages de référence d’une toute autre ampleur (mais d’un tout autre prix. On n’a rien sans rien). En revanche, elles visent à brosser à grands traits les spécificités de Visual Basic, posant ainsi les fondations d’un apprentissage technique plus approfondi.

Ajoutons que ce cours serait vide de sens sans les exercices – et les corrigés – qui l’accompagnent.

Merci de votre attention, vous pouvez reprendre votre sieste.

En quoi un langage objet diffère-t-il d’un langage normal ? On peut résumer l’affaire en disant qu’un langage objet possède toutes les caractéristiques d’un langage traditionnel, avec deux grands aspects supplémentaires.

Donc, c’est un premier point, on peut tout à fait programmer dans un langage objet comme on programmerait du Fortran, du Cobol ou du C. Selon le vieil adage, qui peut  le plus peut le moins. En pratique, cela voudrait dire négliger tout ce qui fait la spécificité d’un tel langage, comme - entre autres - la prise en charge de l’environnement graphique Windows.

Cela implique également que toutes les notions fondamentales que le programmeur a mises en pratique en algorithmique ou en programmation dans un langage traditionnel conservent leur validité pleine et entière : comme tout langage, un langage objet ne connaît que quatre grands types d’instructions : affectations de variables, tests, boucles et entrées / sorties (encore que, nous le verrons, ce dernier type puisse y connaître de fait un certain nombre de bouleversements). Comme tout langage, un langage objet connaît des variables de différents types (numérique, caractère, booléen), et des variables indicées (tableaux). Donc, encore une fois, tout ce qui était vrai dans la programmation traditionnelle demeure vrai dans la programmation objet.

Mais celle-ci offre comme on vient de le dire deux nouveaux outils, redoutables de puissance, à la trousse du programmeur.

1.1.1 Présentation

La première particularité d’un langage objet est de mettre à votre disposition des objets. Etonnant, non ?

Un objet peut être considéré comme une structure supplémentaire d’information, une espèce de super-variable. En effet, nous savons qu’une variable est un emplacement en mémoire vive, caractérisé par une adresse – un nom – et un type (entier, réel, caractère, booléen, etc.). Dans une variable, on ne peut stocker qu’une information et une seule. Même dans le cas où l’on emploie une variable indicée – un tableau – les différents emplacements mémoire ainsi définis stockeront tous obligatoirement des informations de même type.

Un objet est un groupe de variables de différents types. Il rassemble ainsi couramment des dizaines d’informations très différentes les unes des autres au sein d’une même structure, rendant ainsi ces informations plus faciles à manier.

A la différence de ce qui se passe avec un tableau, les différentes variables d’un même objet ne sont pas désignées par un indice, mais par un nom qui leur est propre. En l’occurrence, ces noms qui caractérisent les différentes variables au sein d’un objet s’appellent des propriétés de l’objet. Conséquence, toute propriété d’objet obéit strictement aux règles qui s’appliquent aux variables dans tout langage (type, taille, règles d’affectation…).

On dira également que plusieurs objets qui possèdent les mêmes propriétés sont du même type, ou encore pour mieux frimer, de la même classe. Clââââsse !

A titre d’exemple, prenons un objet d’usage courant : un ministre.

Les propriétés d’un ministre sont : sa taille, son poids, son âge, son portefeuille, le montant de son compte en Suisse, son nom, sa situation par rapport à la justice, etc.

On peut retrouver aisément le type de chacune de ces propriétés :

1.1.2 Syntaxe

La syntaxe qui permet de désigner une propriété d’un objet est :

Par exemple, nous pouvons décider que le montant du compte en Suisse du ministre Duchemol s’élève modestement à 100 000 euros. Si la propriété désignant ce compte pour les objets de type (de classe) ministre est la propriété CompteSuisse, on écrira donc l’instruction suivante :

Pour affecter à la variable Toto le montant actuel du compte en Suisse du ministre Duchemol, on écrira :

Pour augmenter de 10 000 euros le montant du compte en Suisse de Duchemol, on écrira :

Et, vraiment juste histoire d’utiliser une propriété booléenne, et parce que Duchemol n'est pas le seul objet de la classe ministre :

On répète donc qu’hormis ce qui concerne la syntaxe, l’usage des propriétés des objets ne se différencie en rien de celui des variables classiques.

1.1.3 Méthodes

Les langages objet ont intégré une autre manière d’agir sur les objets : les méthodes.

Une méthode est une action sur l’une – ou plusieurs - des propriétés d’un objet.

Une méthode va supposer l’emploi d’un certain nombre d’arguments, tout comme une fonction. On trouvera donc des méthodes à un argument, des méthodes à deux arguments (plus rares), et aussi des méthodes sans arguments.

Ce n’est pas le seul point commun entre les méthodes et les fonctions.

On sait qu’une fonction peut : soit accomplir une tâche impossible si elle n’existait pas, soit accomplir une tâche possible par d’autres moyens, mais pénible à mettre en œuvre.

De la même manière, certaines méthodes accomplissent des tâches qui leur sont propres, et qui ne pourraient pas être accomplies si elles n’existaient pas. D’autres méthodes ne sont là que pour soulager le programmeur, en permettant de modifier rapidement un certain nombre de propriétés.

Par exemple, reprenons le cas notre ministre. Une méthode pourrait être AugmenterPatrimoine, qui supposerait un argument de type numérique. On pourrait ainsi écrire :

Duchemol.AugmenterPatrimoine(10 000)

Ce qui aurait en l’occurrence exactement le même effet que de passer par la propriété correspondante :

1.1.4 Conclusion

Pour terminer sur ce sujet, il faut bien faire attention à une chose lorsqu’on utilise des objets.

En attendant, l’essentiel de nos efforts va consister à comprendre comment on peut se servir des objets (en particulier des contrôles) écrits par d’autres. Et pour ceux qui trouveraient - ils auraient raison - que ces quelques lignes sont loi d'épuiser le sujet, je leur donne rendez-vous au dernier chapitre de ce cours.

On en arrive à la deuxième grande possibilité supplémentaire des langages objet par rapport aux langages traditionnels.

En PASCAL ou en C, par exemple, une application est constituée d’une procédure principale contenant la totalité du code (y compris par l’appel indirect à des sous-programmes). Les instructions qu’elle contient sont exécutées les unes après les autres, jusqu’à la fin (je passe pudiquement sous silence l’improbable hypothèse d’un arrêt prématuré pour cause d’erreur).

Le point fondamental est que dans un tel langage, l’ordre d’exécution des procédures et des sous-procédures est entièrement fixé d’avance par le programmeur lui-même, par le biais des instructions d’appel des sous-procédures. Par ailleurs, et ce n’est pas un hasard, ces procédures portent des noms arbitraires fixés par le programmeur, hormis le cas particulier de la procédure principale, qui se doit de porter un nom particulier, fixé par le langage (généralement, Main).

Dans un langage objet, on peut, si on le désire, conserver intégralement ce mode de fonctionnement. Mais ce n’est plus le seul possible.

En effet, dans un langage objet, il n’y a donc plus à proprement parler de procédure principale ; en tout cas, l’existence d’une procédure principale n’a rien d’obligatoire.

Chaque procédure est liée à la survenue d’un événement sur un objet, et sera donc automatiquement exécutée lorsque cet événement se produit. Le nom de la procédure est alors, de manière obligatoire, le nom de la combinaison objet-événement qui la déclenche.

Résumons-nous. Un petit dessin vaut parfois mieux qu’un grand discours :

Le lien entre l'objet, la survenue de l’événement et le déclenchement de la procédure est établi par le nom de la procédure lui-même. Ainsi, le nom d’une procédure événementielle répond à une syntaxe très précise :

Par exemple, la procédure suivante :

Se déclenche si et seulement si l’utilisateur clique sur l’objet dont le nom est "Machin". Si on prend le problème dans l’autre sens : si je suis programmeur, et que je veux qu’il se passe ceci et cela lorsque l’utilisateur clique sur le bouton appelé "Go", je dois créer une procédure qui s’appellera obligatoirement Sub Go_Click() et qui contiendra les instructions "ceci" et "cela".

Moralité : Ecrire un programme qui exploite l’interface Windows, c’est avant tout commencer par définir :

A la différence d’un programme traditionnel, les procédures liées aux différents événements possibles ne seront donc pas toujours exécutées dans le même ordre : tout dépend de ce que fera l’utilisateur.

Mais bien sûr, à l’intérieur de chaque procédure, les règles traditionnelles de programmation restent vraies. C’est déjà ça de pris.

Si vous avez bien compris ce qui précède, vous avez accompli 80 % de la tâche qui vous attend en ce second semestre. Non, ce n’est pas de la démagogie. J’ai bien dit : « si vous avez bien compris ».

Lorsqu’on écrit une application Visual Basic (on ne traite ici que du cas standard, il en existe d’autres, mais qui sortent du sujet du cours), on crée donc un ensemble d’objets à partir des classes proposées, et on définit les procédures qui se rapportent à ces objets. Lorsqu’on sauvegarde cette application, Visual Basic va créer un certain nombre de fichiers. Pour l’essentiel :

La destruction de l’un quelconque de ces fichiers vous portera naturellement un préjudice que l’on ne saurait sous-estimer.

D’autre part, je tiens à signaler dès maintenant qu’il est extrêmement périlleux de procéder à des "copier – coller" de Form, car le fichier structure (vbp) possède une tendance affirmée à se mélanger complètement les crayons en pareil cas.

Conclusion, on crée un nouveau projet à chaque nouvelle application, et on ne déroge jamais à cette règle d’or. Il ne doit jamais y avoir deux projets ouverts en même temps dans la même fenêtre VB, sous peine de graves représailles de la part du logiciel.

Tant que votre projet est ouvert sous cette forme d’une collection de fichiers vbp et frm, vous pouvez naturellement l’exécuter afin de le tester et de jouer au célèbre jeu des 7 777 erreurs. Lors de l’exécution, le langage est alors ce qu’on appelle « compilé à la volée ». C’est-à-dire que VB traduit vos lignes de code au fur et à mesure en langage machine, puis les exécute. Cela ralentit naturellement considérablement l’exécution, même si sur de petites applications, c’est imperceptible. Mais dès que ça commence à grossir…

Voilà pourquoi, une fois l’application (le "projet") mis au point définitivement, VB vous propose de le compiler une bonne fois pour toutes, créant ainsi un unique fichier *.exe. Ce fichier contient cette fois à lui seul l’ensemble de votre projet, form, code, et tutti quanti. Et il peut naturellement être exécuté sans l’ouverture – donc la possession - préalable de Visual Basic (à un détail près, que nous réexaminerons plus loin dans ce cours).

Un projet terminé est donc un projet compilé.

Et qui, accessoirement, fonctionne sans erreurs.

Je ne me lancerai pas ici dans la description exhaustive de l’interface très riche (trop ?) de ce langage. Vous pourrez trouver ce type de descriptif dans n’importe quel manuel du commerce. Cette partie a pour seul but de signaler les points importants.

Fenêtre d'une application VB en exécution Pas à Pas