Principes de base de la programmation

Le Visual Basic est un langage de programmation complet prenant en charge les constructions de programmation trouvées dans la plupart des autres langages de programmation modernes. Le Visual Basic propose les composantes suivantes : une structure d'application, des variables, des modules, des procédures, des structures de contrôle et une mécanique d'écriture de code.

Structure d'une application Visual Basic

Votre application peut contenir plusieurs types de fichiers différents :

• Les modules de Form (.FRM) contiennent les éléments visuels d'un formulaire, y compris tous les contrôles du formulaire et le code de base associé à ce formulaire.
• Les modules standard (.BAS) et de classe (.CLS) contiennent du code de base.
• Les contrôles personnalisés (.VBX ou .OCX) incluent des contrôles spécialisés, ainsi que des versions améliorées des contrôles standard.
• Un fichier de ressources unique (.RES) contient des chaînes de caractères et des bitmaps utilisés par votre application.

Par défaut, votre projet contient un seul module de formulaire. Vous pouvez ajouter des modules supplémentaires de formulaire, de classe et standard, des contrôles personnalisés et un fichier de ressources, si nécessaire.

Fonctionnement d'une application événementielle

Un événement est une action reconnue par un formulaire ou un contrôle. Une application événementielle exécute du code de base en réponse à un événement. Chaque formulaire et contrôle dans Visual Basic possède un ensemble prédéfini d'événements. Si l'un de ces événements se produit, le Visual Basic appelle le code dans la procédure événementielle associée. Bien que les objets dans Visual Basic reconnaissent automatiquement un ensemble prédéfini d'événements, vous déterminez si et comment ils répondent à un événement particulier. Lorsque vous souhaitez qu'un contrôle réponde à un événement, vous écrivez du code appelé procédure événementielle pour cet événement. De nombreux objets reconnaissent le même événement, bien que différents objets puissent exécuter différentes procédures événementielles lorsque l'événement se produit. Par exemple, si un utilisateur clique sur un formulaire, la procédure événementielle Form_Click s'exécute; si un utilisateur clique sur un bouton de commande nommé Command1, la procédure événementielle Command1_Click est exécutée.

Voici ce qui se passe dans une application événementielle typique :

• L'application démarre et le formulaire de démarrage est automatiquement chargé et affiché.
• Un formulaire ou un contrôle reçoit un événement. L'événement peut être provoqué par l'utilisateur (par exemple, une frappe sur une touche), par le système (par exemple, un événement de minuterie) ou indirectement par votre code (par exemple, un événement Load lorsque votre code charge un formulaire).
• S'il existe une procédure événementielle correspondant à cet événement, elle s'exécute.
• L'application attend le prochain événement.

De nombreux événements se produisent en conjonction avec d'autres événements. Par exemple, lorsque l'événement DblClick se produit, les événements MouseDown, MouseUp et Click se produisent également.

Programmation événementielle versus traditionnelle

Dans une application traditionnelle ou «procédurale», l'application elle-même plutôt qu'un événement contrôle les parties de code s'exécutant. L'exécution commence par la première ligne de code exécutable et suit un chemin défini dans l'application, en appelant les procédures selon les besoins. Dans les programmes événementiels, une action utilisateur ou un événement système exécute une procédure événementielle. Ainsi, l'ordre dans lequel votre code s'exécute dépend des événements se produisant, ce qui dépend à son tour de ce que fait l'utilisateur. C'est l'essence même des interfaces utilisateur graphiques et de la programmation événementielle : l'utilisateur est en charge et votre code répond. Parce que vous ne pouvez pas prédire ce que fera l'utilisateur, votre code doit faire quelques hypothèses sur «l'état du monde» lors de son exécution. Lorsque vous devez faire des hypothèses (par exemple, qu'une zone de texte contient du texte avant d'appuyer sur un bouton de commande), vous devez essayer de structurer votre application afin que ces hypothèses soient toujours valides (par exemple, désactiver le bouton de commande et l'activer uniquement dans la zone de texte de l'événement Change). Votre code peut déclencher des événements supplémentaires lors de certaines opérations. Par exemple, le chargement d'un formulaire provoque l'événement Load du formulaire et la modification de la propriété Text d'une zone de texte provoque l'événement Change de cette zone de texte. Une annulation exécutant une opération dans une procédure événementielle provoquant à nouveau le même événement; provoquera un événement en cascade. Par exemple, si votre code dans la procédure événementielle Change pour une zone de texte définit la propriété Text de cette zone de texte, la procédure événementielle Change est à nouveau appelée, votre code définit à nouveau la propriété Text, provoquant à nouveau l'événement Change, et ainsi jusqu'à ce que Visual Basic génère finalement l'erreur :

Code s'exécutant au démarrage

Par défaut, le premier formulaire de votre application est désigné comme formulaire de démarrage. Lorsque votre application commence à s'exécuter, ce formulaire s'affiche (le premier code à exécuter est donc le code de l'événement Form_Initialize pour ce formulaire). Si vous souhaitez qu'un autre formulaire affiche le démarrage de votre application, vous devez modifier le formulaire de démarrage. Pour changer le formulaire de démarrage :

• Dans le menu Tools, choisissez Options.
• Choisissez l'onglet Project.
• Dans la zone de liste Start Form, sélectionnez le formulaire de votre choix comme nouveau formulaire de démarrage.
• Choisissez OK.

Parfois, vous souhaiterez peut-être que votre application démarre sans aucun formulaire initialement chargé. Par exemple, vous souhaiterez peut-être exécuter du code chargeant un fichier de données, puis affiche l'un des différents formulaires en fonction du contenu du fichier de données. Vous pouvez le faire en créant une procédure Sub appelée Main dans un module standard. Cette procédure doit être une procédure Sub et ne peut pas être dans un module de formulaire. Ensuite, dans le menu Tools, choisissez Options, sélectionnez l'onglet Project et sélectionnez Sub Main dans la zone Startup Form.

Mettre fin à une application

Une application événementielle s'arrête lorsque tous ses formulaires sont fermés et qu'aucun code n'est en cours d'exécution. S'il existe un formulaire masqué lorsque le dernier formulaire visible est fermé, votre application semblera terminée (car aucun formulaire n'est visible) mais continuera en fait à s'exécuter jusqu'à ce que tous les formulaires masqués soient fermés. Cette situation peut se produire car tout accès aux propriétés ou contrôles d'un formulaire déchargé charge implicitement ce formulaire sans l'afficher.

La meilleure façon d'éviter ce problème lors de la fermeture de votre application est de vous assurer que tous vos formulaires sont déchargés. Si vous disposez de plusieurs formulaires, vous pouvez utiliser la collection Forms et l'instruction Unload. Par exemple, sur votre formulaire principal, vous pouvez avoir un bouton de commande nommé cmdQuit permettant à un utilisateur de quitter le programme. Si votre application n'a qu'un seul formulaire, la procédure d'événement Click peut être aussi simple que ceci :

Si votre application utilise plusieurs formulaires, vous pouvez décharger les formulaires en plaçant du code dans la procédure événementielle Unload de votre formulaire principal. Vous pouvez utiliser la collection Forms pour vous assurer de trouver et de fermer tous vos formulaires. Il se peut que vous deviez mettre fin à votre demande sans tenir compte de l'état des formulaires ou objets existants. Le Visual Basic fournit l'instruction End à cet effet.

L'instruction End met immédiatement fin à une application; aucun code après l'exécution de l'instruction End et aucun autre événement ne se produit. En particulier, le Visual Basic n'exécutera pas la procédure événementielle QueryUnload, Unload ou Terminate pour les formulaires. Les références d'objet seront libérées, mais si vous avez défini vos propres classes, le Visual Basic n'exécutera pas les événements Terminate des objets créés à partir de vos classes.

En plus de l'instruction End, l'instruction Stop arrête une application. Cependant, vous ne devez utiliser l'instruction Stop que lors du débogage, car elle ne libère pas les références aux objets.

Variables

Vous devez souvent entreposer temporairement des valeurs lors de l'exécution de calculs avec Visual Basic. Par exemple, vous souhaiterez peut-être calculer plusieurs valeurs, les comparer et effectuer des opérations sur celles-ci, en fonction du résultat de la comparaison. Vous devez conserver les valeurs si vous souhaitez les comparer mais pas les entreposer dans une propriété.

Le Visual Basic, comme la plupart des langages de programmation, utilise des variables pour entreposer les valeurs. Les variables ont un nom (le mot que vous utilisez pour désigner la valeur que contient la variable) et un type de données (déterminant le type de données que la variable peut entreposer).

Déclaration de variables

Vous n'êtes pas obligé de déclarer ou de créer explicitement des variables dans Visual Basic. Si vous utilisez un nom dans votre code n'étant pas le nom d'une variable existante, le Visual Basic crée une nouvelle variable avec ce nom. Cependant, c'est une bonne pratique de programmation de déclarer explicitement vos variables car cela pourrait éviter des problèmes de débogage plus tard. Vous pouvez spécifier que les déclarations de variables sont requises de la manière suivante : dans le menu Tools, choisissez Options, sélectionnez l'onglet Environment, puis choisissez Require Variable Declaration; ou ajoutez une instruction Option Explicit à la section Déclarations de chaque module de formulaire, standard ou classe. Cette situation vous obligera à déclarer vos variables. Vous déclarez une variable avec la syntaxe Dim suivante :

Les variables déclarées avec l'instruction Dim dans une procédure n'existent que tant que la procédure est en cours d'exécution. Lorsque la procédure est terminée, la valeur de la variable disparaît. En outre, la valeur d'une variable dans une procédure est locale à cette procédure, c'est-à-dire que vous ne pouvez pas accéder à une variable dans une procédure à partir d'une autre procédure. Ces caractéristiques vous permettent d'utiliser les mêmes noms de variables dans différentes procédures sans vous soucier des conflits ou des modifications accidentelles. Il existe d'autres moyens de déclarer des variables :

• Déclarer une variable dans la section Déclarations d'un module de formulaire, standard ou classe, plutôt que dans une procédure, rend la variable disponible pour toutes les procédures du module.
• Déclarer une variable à l'aide du mot-clef Public le rend disponible dans toute votre application.
• La déclaration d'une variable locale à l'aide du mot clef Static préserve sa valeur même lorsqu'une procédure se termine.

Entreposage et récupération de données dans des variables

Vous utilisez des instructions d'affectation pour effectuer des calculs et affecter le résultat à une variable :

Types de données

Par défaut, les variables Visual Basic sont du type de données Variant. Le type de données Variant peut entreposer des tableaux et des objets, des données numériques, de date/heure ou de chaîne de caractères. Vous n'avez pas à convertir entre ces types de données lorsque vous les affectez à une variable Variant; le Visual Basic effectue automatiquement toute conversion nécessaire. Cependant, si vous savez qu'une variable entreposera toujours des données d'un type particulier, le Visual Basic peut gérer ces données plus efficacement si vous déclarez une variable de ce type.

Modules

Le code dans Visual Basic est entreposé dans des modules. Il existe trois types de modules; modules de classe, modules de formulaire (les modules de formulaire sont un type de module de classe) et modules standard.

Les applications simples peuvent consister en un seul formulaire et tout le code de l'application réside dans ce module de formulaire. Au fur et à mesure que votre application devient plus volumineuse et plus sophistiquée, vous ajoutez des formulaires supplémentaires. Finalement, vous constaterez peut-être qu'il existe du code commun que vous souhaitez exécuter sous plusieurs formes. Vous ne souhaitez pas dupliquer le code dans les deux formulaires, vous créez donc un module distinct contenant une procédure mettant en oeuvre le code commun. Ce module séparé doit être un module standard. Au fil du temps, vous pouvez créer une bibliothèque de modules contenant des procédures partagées.

Chaque module standard, classe et formulaire peut contenir :

• Déclarations : Vous pouvez placer des déclarations de procédure de constante, de type, de variable et de DLL au niveau du module des modules de formulaire, de classe ou standard.
• Procédures : Une procédure Sub, Function ou Property contient des morceaux de code pouvant être exécutés en tant qu'unité.

Modules de formulaires

Les modules de formulaire (extension de nom de fichier .FRM) sont la base de toute application Visual Basic. Ils peuvent contenir des descriptions graphiques du formulaire et de ses contrôles, y compris leurs paramètres de propriété. Ils peuvent également contenir des déclarations au niveau du formulaire de types, constantes, variables et procédures externes; les procédures gérant les événements; et procédures générales. Pratiquement tout ce qui s'applique aux modules de classe s'applique aux formulaires. Les formulaires ne sont que des modules de classe sur lesquels des contrôles peuvent être placés et afficher une fenêtre de formulaire. Les formulaires sont la partie de votre application étant visible par les utilisateurs au moment de l'exécution.

Modules standard

Les modules standard (extension de nom de fichier .BAS) sont des conteneurs pour les procédures et les déclarations couramment utilisées par d'autres parties de l'application. Ils peuvent contenir des déclarations globales ou au niveau du module de types, constantes, variables, procédures externes et procédures globales.

Modules de classe

Les modules de classe (extension de nom de fichier .CLS) sont la base de la programmation orientée objet dans Visual Basic. Vous pouvez écrire du code dans des modules de classe pour créer de nouveaux objets. Ces nouveaux objets peuvent inclure vos propres propriétés et méthodes personnalisées, bien que les objets personnalisés ne puissent pas avoir leurs propres événements. Toutes les propriétés et méthodes que vous créez peuvent également être utilisées par d'autres objets de votre application. Vous pouvez également utiliser le mot-clef New pour créer plusieurs copies de vos objets.

Procédures

Vous pouvez simplifier les tâches de programmation en divisant les programmes en composantes logiques plus petits. Ces composantes, appelés procédures, peuvent alors devenir des blocs de construction vous permettant d'améliorer et d'étendre Visual Basic. Les procédures sont utiles pour condenser les tâches répétées ou partagées, telles que les calculs fréquemment utilisés, la manipulation de texte et de contrôle et les opérations de base de données. La programmation avec des procédures présente deux avantages majeurs :

• Les procédures vous permettent de diviser vos programmes en unités logiques discrètes, dont chacune peut être déboguée plus facilement qu'un programme entier sans procédures.
• Les procédures utilisées dans un programme peuvent servir de blocs de construction pour d'autres programmes, généralement avec peu ou pas de modifications. Il existe plusieurs types de procédures utilisées dans Visual Basic.

Une procédure peut être une procédure Sub, Function ou Property :

• Les procédures Sub ne renvoient pas de valeur.
• Les procédures Function renvoient une valeur.
• Les procédures Property peuvent renvoyer et affecter des valeurs et définir des références à des objets.