Les sections suivantes fournissent des informations utiles sur VBA. Les noms d’objets sont fournis afin que vous puissiez facilement les examiner dans la base de données Northwind 2.0 Starter Edition.
VBA (Visual Basic pour Applications) est le langage de programmation utilisé dans tous les produits Microsoft 365, et pas seulement Dans Access. Il est principalement documenté ici : Documentation du développeur Access.Pour commencer, consultez Présentation de la programmation Access.
Lorsque vous recherchez des informations, veillez à rechercher des exemples spécifiques à Access et à inclure Microsoft Access dans le terme de recherche. Souvent, les solutions pour les autres produits Microsoft 365 fonctionnent, mais peuvent nécessiter des modifications.
Microsoft Access est un produit mature. Cela signifie qu’il y a beaucoup d’exemples là-bas, ce qui est très bien pour vous. Cela signifie également que les livres plus anciens sur la programmation Access sont toujours viables pour vous. La plupart des livres plus anciens sont encore disponibles sur les sites de livres d’occasion à une fraction de leur coût d’origine.
Les fichiers Microsoft Access sont des fichiers Microsoft 365. Les fichiers Microsoft 365 doivent se trouver dans un emplacement approuvé ou leur contenu doit être activé. Ces éléments sont considérés comme sûrs parce que vous les avez créés ou qu’ils proviennent d’une source digne de confiance. Cette vérification se produit chaque fois que vous ouvrez un fichier Microsoft 365. Nous l’appellerons approuvé/activé à partir d’ici. Si une nouvelle version de l’application est publiée et ouverte à partir d’un emplacement non approuvé, le processus d’activation du contenu se répète. Pour plus d’informations, consultez Emplacements approuvés pour les fichiers Microsoft 365, Décider s’il faut approuver une base de données et Ajouter, supprimer ou modifier un emplacement approuvé dans Microsoft 365.
Les macros, fonctions et sous-procédures sont la façon dont vous implémentez la logique métier dans votre base de données Access.
Les contrôles d’un formulaire (tels que des boutons, des zones de texte, des étiquettes, etc.) peuvent utiliser leurs événements (comme cliquer sur le contrôle) pour déclencher d’autres processus, tels que l’ajout, la suppression d’enregistrements ou l’ouverture de formulaires. Ces processus peuvent être implémentés à l’aide de macros ou de VBA. Northwind utilise principalement des macros et des vba. Pour plus d’informations, consultez Exécuter l’action de macro Coder.
Certains types de contrôle ont des Assistants intégrés qui créent automatiquement une macro. Par exemple, l’ajout d’un bouton de commande à un formulaire ouvre un Assistant qui offre plusieurs options de fonctionnalités pour le bouton. L’ajout d’une zone de liste déroulante ouvre un Assistant qui peut être configuré pour rechercher un enregistrement particulier dans le formulaire.
Le volet de navigation est le principal moyen d’afficher et d’accéder à tous vos objets de base de données. Il s’affiche par défaut sur le côté gauche de la fenêtre Access. Le volet de navigation de Northwind 2.0 Starter Edition a été personnalisé. Nous avons créé une catégorie personnalisée appelée Northwind Starter 2.0. Cela nous permet d’organiser les objets par zone fonctionnelle. Pour plus d’informations, consultez Personnaliser le volet de navigation.
Il est important pour vous d’en savoir plus sur l’étendue et la visibilité dans Access et Microsoft 365. L’étendue fait référence à la disponibilité d’une variable, d’une constante ou d’une procédure pour une autre procédure. Il existe trois niveaux d’étendue : au niveau de la procédure, au niveau du module privé et au niveau du module public. Vous déterminez l’étendue d’une variable lorsque vous la déclarez. Il est judicieux de déclarer explicitement toutes les variables pour éviter les erreurs de conflit d’affectation de noms entre les variables avec des étendues différentes. Tous les modules ont deux instructions de directive : Option Compare Database et Option Explicit. Pour plus d’informations, consultez Comprendre l’étendue et la visibilité, Instruction publique, Instruction privée, Instruction statique et Comprendre la durée de vie des variables.
Parfois, vous avez besoin qu’une variable existe après que l’objet qui l’a créée sort de l’étendue. Il existe trois méthodes principales pour effectuer cette opération : Variables publiques, TempVars et stockage des valeurs dans une table locale. Chacun d’entre eux a des avantages et des inconvénients. De nombreux développeurs utilisent une combinaison de ces éléments.
Les variables publiques et TempVars existent pour la session active et sortent de l’étendue lorsque l’application est fermée. Que se passe-t-il si vous souhaitez conserver des variables spécifiques à l’utilisateur pendant leurs sessions ? Vous pouvez stocker ces types de valeurs dans une table locale. Dans Northwind 2.0 Starter Edition, nous avons ces valeurs dans une table appelée SystemSettings. Par exemple, une valeur dans la table est « ShowWelcome ». Cette valeur nous indique si vous souhaitez voir l’écran d’accueil chaque fois que vous vous connectez ou non.
Si vous avez utilisé des Assistants de contrôle intégrés à Access, vous savez que si une macro est créée, il n’y a souvent aucune gestion des erreurs, et si VBA est créé, il peut être limité à une fonction MsgBox, style Err.Description.
Dans Northwind 2.0 Starter Edition, nous avons implémenté ce qu’on appelle un gestionnaire d’erreurs global. Les erreurs qui se produisent dans une procédure appellent une fonction au niveau global pour afficher l’erreur. Le gros avantage est que le code est cohérent et que si le message doit être modifié, par exemple en affichant le numéro d’erreur ou en journaldant l’erreur dans un fichier, il ne peut être effectué qu’à un seul emplacement.
clsErrorHandler est le module de classe qui implémente le code de gestion des erreurs. Un module de classe conserve toutes ses fonctions principales et d’assistance dans une unité, ce qui rend le code plus encapsulé. La macro AutoExec finit par appeler la fonction de démarrage dans modStartup, elle crée une instance de clsErrorHandler et l’enregistre en tant que variable globale afin qu’elle puisse être utilisée dans toute l’application.
En fait, le code de gestion des erreurs dans les procédures est si cohérent que nous avons pu créer tout cela en moins de cinq minutes à l’aide d’un code VBA sophistiqué qui a équipé chaque procédure du gestionnaire d’erreurs approprié. Ce code n’est pas inclus dans le modèle.
