Cours VB.Net - Plus loin avec les objets

Une remarque pertinente ?
Une critique impertinente ?
Un lynchage en règle ?
Une invitation sous les tropiques ?

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)

Ne manquez surtout pas
mon groupe de rock, les fabuleux
Midnight Jokers !

Jouer du rock c'est bien,
jouer de la country,
c'est bien aussi !
Écoutez aussi les improbables
Moonlight Swampers !

Vous aimez les petites bêtes qui vivent sous l'eau ?
Faites donc un tour vers mes photos sous-marines

Partie 2

L'interface de Visual Studio

Après avoir fait connaissance des concepts de la programmation objet, nous allons dans ce chapitre nous familiariser avec l'interface VB, c'est-à-dire avec les principaux outils que nous offre l'environnement de développement Visual Studio. "Oui, mais c'est quand qu'on commence à programmer ?" Ça vient, ça vient, patience...

1. Structure des applications

La première chose à faire, c'est d'assimiler l'architecture des édifices que nous allons créer et le vocabulaire qui va avec. Et ça, ce n'est pas rien, tant à côté d'une application VB, les plans d'une usine à gaz sont d'une simplicité biblique. Mais enfin, pas le choix, et autant consacrer quelques minutes à se mettre les idées au clair plutôt que perdre ensuite des heures juste parce qu'on s'est mélangé les pinceaux dans les arborescences et les dénominations.

Alors, une application VB.NET, c'est quoi ? C'est :

un ensemble de fichiers formant ce qu'on appelle le code source, écrit dans le langage Visual Basic.
un fichier exécutable, produit à partir de ce code source. Rappelons que le fait d'engendrer un fichier exécutable à partir du code source s'appelle la compilation.

En ce qui concerne le code source, VB va l'organiser de la manière suivante :

le point de départ d'une application VB, c'est une solution. Lorsqu'on crée une nouvelle solution, VB demande pour celle-ci un nom et un répertoire. Aussi sec, il va alors faire trois choses :
1. créer à l'emplacement indiqué le répertoire portant le nom de la solution.
2. dans ce répertoire, toujours avec le nom de la solution, créer un fichier *.sln contenant les informations de la solution.
3. et toujours dans ce répertoire, toujours avec le nom de la solution, créer un fichier caché *.suo , contenant les options choisies dans Visual Basic par le programmeur qui a développé la solution.
Mais ce n'est qu'un combat, continuons le début. En effet, dans nos solutions Visual Basic, nous allons devoir insérer nos applications, c'est-à-dire nos projets. Si on le souhaite, une même solution peut contenir plusieurs, voire des dizaines de projets. Cela dit, je ne recommande pas cette stratégie. Nous considèrerons donc, en tant que débutants, qu'une application VB = un projet = une solution.
Il va toutefois falloir procéder avec doigté si on ne veut pas que notre disque dur devienne rapidement un foutoir innommable. En effet, chaque projet est lui aussi caractérisé par un nom et un répertoire de sauvegarde. Mais, et c'est là que c'est fort, ce répertoire n'est pas forcément un sous-répertoire de la solution qui contient le projet - même si lorsqu'on débute, ce soit très vigoureusement recommandé.
Il n'y a donc pas de rapport entre le fait que les objets "solution" contiennent les objets "projets", et le fait que le répertoire où est enregistrée la solution contienne les répertoires où sont enregistrés les projets...
Mal à la tête ? C'est l'effet Petitmou. Toujours est-il que VB va non seulement créer un répertoire au nom du projet, mais qu'il va mettre dans ce répertoire toute une série de fichiers, dont un fichier au nom du projet et à extension *.vbproj, fichier dans lequel est stockée toute la structure du projet.

Remarque fort utile :
Il faut faire très attention lorsqu'on incorpore un projet dans une solution : en effet, la commande Nouveau projet entraîne obligatoirement la création d'une nouvelle solution. En revanche, pour insérer un projet dans une solution existante, il faut choisir Ajouter un projet.

Enfin, nous voilà arrivés au bout de notre quête : dans chaque projet, il y a un certain nombre d'éléments de base. Ces éléments sont, pour l'essentiel, des Form, ou formulaires. Une application windows basique compte un seul formulaire, et une application complexe peut en rassembler plusieurs dizaines. Chaque formulaire sera sauvegardé dans un fichier différent, dont l'extension sera *.vb. Il faut noter que c'est dans ces fichiers *.vb que se trouve le code proprement dit, celui-là même que vous allez concevoir à la sueur de votre front altier et entrer dans la machine de vos petits doigts graciles. Alors, autant y faire attention et veiller à ce que les sauvegardes soient faites correctement.

Conclusion : quelques conseils de base
Les débutants que nous sommes appliqueront donc impérativement les règles suivantes :
- une solution par projet, un projet par solution
- le projet devra être sauvegardé dans un sous-répertoire de la solution

En ce qui concerne l'exécutable, il y a quelques petites choses à dire. A la différence de certains autres langages, VB.NET ne produit pas un code directement exécutable par toutes les machines. Les instructions contenues dans un exécutable VB.NET sont écrites dans un langage appelé MSIL, pour MicroSoft Intermediate Langage. Comme son nom l'indique, ce langage s'adresse à des couches "intermédiaires" de la machine, à savoir d'une part Windows lui-même, d'autre part à une couche logicielle poétiquement appelée le Framework .NET (qu'on peut traduire par "infrastructure .NET").

Pour pouvoir exécuter un exécutable VB.NET, une machine doit donc impérativement comporter ce Framework.NET, que l'on peut télécharger gratuitement sur le site de Microsoft. Encore heureux.

Comment déclencher la compilation ? En passant par la commande Générer, qui propose le(s) nom(s) des projets de la solution encours. Le fichier exe est alors généré dans le sous-répertoire bin correspondant au projet.

Remarque utilitaire :
Lorsqu'on écrit un programme, point n'est besoin de générer un exécutable en bonne et due forme à chaque fois que l'on souhaite tester le résultat provisoire de notre travail. VB offre la possibilité de lancer l'exécution d'une application directement à partir de la source.
En réalité, il procède dans ce cas à une compilation rapide, sans nous embêter avec des questions superflues, et exécute le produit de cette compilation dans la foulée.
Cela permet de différer la réalisation de la compilation définitive au moment où le programme aura été testé, et certifié sans erreurs par vos bons soins !

Pour améliorer les petits détails liés au fichier exécutable et à la compilation, on y reviendra... plus tard.

2. Prise en main de Visual Basic

Le logiciel Visual Basic Studio est là pour nous faciliter l'écriture de programmes, en particulier (mais pas seulement) en mettant à notre disposition, sous une forme facilement accessible, les classes Windows les plus communes (boutons, listes, cases, et tout ce qui s'essuie).

2.1 Les deux fenêtres principales

Lorsqu'on va la programmer via Visual Studio, une application va donc toujours pouvoir être abordée sous deux angles complémentaires :

l'aspect graphique, visuel, bref, son interface. Dans la fenêtre principale de VB, nous pourrons facilement aller piocher les différents objets que nous voulons voir figurer dans notre application, les poser sur notre formulaire, modifier leurs propriétés par défaut, etc :
le code proprement dit, où nous allons entrer les différentes procédures en rapport avec le formulaire en question :

Bâtir une application VB, c'est généralement faire de fréquents allers-retours entre les deux représentations. Pour cela, rien de plus facile : il suffit de se servir des onglets disponibles sur le haut de chaque fenêtre.

2.2 Créer des contrôles à partir des classes standard

Définition :
Un contrôle est un objet créé à partir de certaines des classes définies dans Windows.
En standard, VB propose plusieurs rubriques au sein de sa boîte à outils, et rien que dans la principale d'entre elles, la rubrique Windows Forms, une quarantaine de contrôles, ce qui ouvre déjà bien des horizons.
En réalité, le nombre des contrôles disponibles est donc bien supérieur. Mais nous en reparlerons... plus tard.

Créer des contrôles à partir des classes proposées en standard est extrêmement simple. Il suffit d'aller piocher d'un clic de souris le contrôle voulu dans la boîte à outils (qui, dans la configuration normale, se trouve à gauche de l'écran) et d'effectuer un cliquer-glisser sur le formulaire pour donner à ce contrôle la taille et l'emplacement voulus. A signaler, pour les fainéants indécrottables, qu'un simple double-clic dans la boîte à outils constitue une agréable solution alternative.

Par la suite, on peut toujours modifier l'emplacement et la taille d'un contrôle, d'un simple coup de souris bien placé.

Pour supprimer un contrôle, c'est encore plus simple : on le sélectionne, et ensuite la bonne vieille touche SUPPR le désintègrera et le fera retourner au néant.

Si l'on veut manipuler plusieurs contrôles du formulaire à la fois, on peut sélectionner toute une zone (par un habile cliquer-glisser), ou encore sélectionner individuellement chaque contrôle en maintenant la touche CTRL enfoncée. Bref, que du très banal pour les utilisateurs avertis de Windows que vous êtes.

2.3 La fenêtre des propriétés

Chaque fois qu'un contrôle (ou plusieurs) est sélectionné, la fenêtre des propriétés (située en standard à droite de l'écran) affiche les valeurs associées à ce contrôle. C'est-à-dire que se mettent à jour la liste des propriétés (qui comme on l'a vu varie d'une classe, donc d'un contrôle, à l'autre) et la valeur de ces propriétés (qui varie d'un contrôle à l'autre, même lorsqu'ils sont de la même classe).

Les propriétés qui sont affichées là sont les propriétés par défaut du contrôle. Ce sont celles qu'aura le contrôle au moment du lancement de l'application. Bien sûr, par la suite, il n'est pas exclu que ces propriétés soient modifiées, notamment par des lignes de code (c'est même généralement un des principaux objectifs des lignes de code, quand on y réfléchit bien). Mais encore une fois, pour fixer les propriétés voulues pour chaque contrôle au lancement de l'application, le plus simple est de fixer à la main, sans code, les valeurs désirées dans cette fameuse fenêtre des propriétés.

2.4 L'éditeur de code

Passons au code. Visual Studio, dans sa grande magnanimité, va tâcher de faire au mieux pour nous faciliter la vie. Il va en fait décrypter notre code au fur et à mesure de sa rédaction, et nous donner en temps réel des indications via des codes de couleur, comme on peut le voir (avec de bonnes lunettes) sur l'image ci-dessus. Ainsi :

les titres de procédures seront écrits en gris
les mots-clés du langage seront portés en bleu
les commentaires seront en vert
Et last but not least, toute ligne comportant une faute de syntaxe, ou posant un problème au compilateur, sera immédiatement soulignée. Qui plus est, il suffira d'amener le curseur de la souris au-dessus de l'erreur pour que la raison en soit immédiatement affichée dans une bulle d'aide (mais aussi, hélas, dans un vocabulaire souvent incompréhensible, il ne faut pas rêver non plus). On dispose donc d'un premier outil de déboguage, très pratique, nous assurant que la syntaxe de notre code sera toujours irréprochable. Cela dit, comme vous le savez, la syntaxe n'est pas la seule source d'erreurs dans un programme...

Ce n'est pas tout. Lorsque nous tapons dans le code un nom d'objet, et pour peu que ce nom soit reconnu (c'est-à-dire qu'il existe bel et bien un objet de ce nom dans notre application), sitôt que nous entrons le point qui termine le nom de l'objet, apparaît une liste déroulante avec l'intégralité des propriétés et méthodes disponibles pour cet objet. Ce qui veut dire, inversement que :

Remarque finaude :
Si lors de la frappe du point qui suit un nom d'objet, aucune liste déroulante n'apparaît, c'est que cet objet n'est pas reconnu par le langage.
Cela signifie soit que le nom a été mal orthographié, soit qu'on s'évertue à faire référence à un objet inexistant... De toutes façons, c'est un signal d'alarme qui dénote un problème !

Enfin, comme nous sommes dans un langage qui est un langage structuré, le code est organisé sous forme de blocs qui peuvent être déployés ou masqués, pour plus de lisibilité, via les petites icônes placés à gauche de la tête de chaque bloc. Il ne faut pas hésiter à jouer de cet outil bien pratique pour s'y retrouver dès que l'application commence à grossir.