Cours VB.Net - Plus loin avec les objets


Une remarque pertinente ? Une critique impertinente ? Un lynchage en règle ? Une invitation sous les tropiques ? Ecrivez-moi !
	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 MECI (Université Paris 7)

LE COURS Préambules Nécessaires 1. VB.NET, un langage objet 2. L'interface de Visual Studio 3. Premiers contrôles 4. Les bases du langage 5. D'autres contrôles 6. Les collections 7. Encore des contrôles 8. Événements insolites 9. La chasse aux bugs 10. Toujours des contrôles 11. Les graphismes 12. Les menus 13. Distribuer une application 14. Les fichiers texte 15. VB.NET et Windows 16. Plus loin avec les objets 17. Les applications MDI CHOSES DIVERSES Souvent Posées Questions Liens utiles	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 la structure des fichiers sources d'une application VB a une fâcheuse tendance à ressembler aux plans d'une usine à gaz. 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, l'ensemble le plus large de fichiers source, s'appelle 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 : créer à l'emplacement indiqué le répertoire portant le nom de la solution. dans ce répertoire, toujours avec le nom de la solution, créer un fichier .sln contenant les informations de la solution. 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 dite concepteur de vues 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 fenêtre contenant 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, ou de passer par le menu contextuel via un clic droit. 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, et qui possède la capacité à interagir avec les actions de l'utilisateur. Tous les contrôles sont donc des objets, mais tous les objets ne sont donc pas des contrôles. Cela dit, dans le cadre de ce cours, l'énorme majorité des objets que l'on utilisera sont des contrôles — dans le cas contraire, je ne manquerai pas de le signaler explicitement. En standard, VB propose plusieurs rubriques au sein de sa boîte à outils ; rien que dans la principale d'entre elles, la rubrique Windows Forms, une quarantaine de contrôles sont disponibles, ce qui ouvre déjà bien des horizons (en réalité, le nombre des contrôles potentiellement accessibles est bien supérieur, mais chaque chose en son temps). 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. Remarque avisée : Lorsqu'on crée ainsi des contrôles de manière graphique, par de simples clics de sours, en réalité, on écrit du code* - ou, plus exactement, on fait écrire automatiquement du code par VB. Celui-ci traduit en effet sous forme d'instructions nos clics de souris. Ces instructions sont naturellement rangées dans la fenêtre code, mais s'agissant des contrôles par défaut, qui seront présents dès le lancement de l'application, ces instructions sont écrites dans une zone a priori cachée de cette fenêtre (qu'un clic au bon endroit peut rendre vsible). 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 en bas à 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 Comment crééer ses procédures évènementielles ? Avant de taper quelque ligne de code que ce soit, il faut se demander dans quelle procédure cette ligne doit figurer. Là, deux possibilités. Ou bien la procédure en question doit être exécutée indépendamment des actions de l'utilisateur, c'est-à-dire qu'elle sera déclenchée par un appel de code. Dans ce cas (très, très rare) on peut écrire soi-même la ligne de titre de cette procédure, selon la syntaxe suivante : Private Sub MaProcédure() ... End Sub Ou bien la procédure est une pocédure événementielle, c'est-à-dire qu'elle devra s'exécuter chaque fois que l'utilisateur accomplia telle ation sur tel contrôle. C'est ainsi dans l'écrasante majorité des cas. Il y a alors trois stratégies possible en théorie (mais seulement deux en pratique). taper soi-même la ligne de titre de la procédure à la main. Mais ça on oublie tout de suite et pour toujours. D'abord, parce que c'est atrocement compliqué : en particulier, il va falloir taper comme il faut les paramètres d'entrée de la procédure, paramètres qui changent selon l'événement concerné. Ensuite, il existe des moyens faciles et simples de faire écrire automatiquement (et sans fautes) cette ligne par Visual Basic. Autant en profiter, on aura bien d'autres occasions de se tordre les méninges pour des choses qui en valent la peine. faire un double-clic sur le contrôle concerné, dans la fenêtre conception. Avantage : l'affaire est réglée en deux dixièmes de secondes : VB crée la procédure et bascule aussi sec sur la fenêtre du code. Inconvénient (forcément, il y en a un) : VB choisit dans ce cas pour créer la procédure l'évènement par défaut en fonction de la classe du contrôle concerné. Par exemple, si c'est un bouton, on aura une procédure gérant le Click. Évidemment, cet évènement par défaut a été choisi de manière à pourvoir aux besoins les plus communs... mais forcément, pas à tous. Dès qu'on souhaite associer à un contrôle un évènement qui n'est pas l'évènement par défaut, on est donc tenu d'utiliser la troisième méthode... on bascule tout d'abord dans la fenêtre de code. Là, on repère les deux listes déroulantes qui se trouvent en haut, côte à côte, juste sous les onglets. Celle de gauche contient tous les contrôles créés sur la Form - on sélectionne celui qui nous intéresse. On va ensuite dans la liste de droite, qui propose l'ensemble des évènements possibles pour le contrôle en question. On sélectionne alors l'évènement voulu et le tour est joué, la procédure est créée. Remarque de survie : De ce qui précède, on déduit aisément que si l'on peut changer autant qu'on veut le nom d'une procédure une fois qu'elle a été créée, il ne faut en revanche jamais changer l'événement auquel elle correspond (et qui figure, je le rappelle, après l'instruction Handles). Remplacer un évènement par un autre entraîne en effet une divergence entre les paramètres en entrée figurant dans la procédure et ceux qui sont attendus par l'évènement en question, et c'est le crash assuré. Moralité, quand on se trompe d'évènement en créant la procédure, pas le choix : on efface et on recommence... 2.5 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 un système de couleurs, comme on peut le voir (avec de bonnes lunettes) sur l'image ci-dessus . Ainsi, sans qu'on ait même besoin de remuer une oreille : les titres de procédures seront automatiquement écrits en gris les mots-clés du langage seront automatiquement portés en bleu les commentaires seront automatiquement 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.