Le contenu ici peut s’appliquer à Northwind 2.0 Developer Edition et Starter Edition.
VBA (Visual Basic pour Applications) est le langage de programmation utilisé dans tous les produits Office. L’apprentissage de VBA vous permet d’utiliser tous les produits Office (pas seulement Access).
Lorsque vous recherchez des « guide pratique », veillez à rechercher des exemples spécifiques à Access et à inclure Microsoft Access dans la recherche. Souvent, les solutions pour les autres produits Office fonctionnent, mais il n’y a aucune garantie. Microsoft Access est un produit mature ; cela signifie qu’il y a beaucoup d’exemples là-bas; ce qui est génial 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. Consultez le site web microsoft pour déterminer quelles versions d’Access sont toujours prises en charge et suivez-les.
Ressources de fin de support pour Office - Déployer Office | Microsoft Learn
Vous trouverez ci-dessous des liens vers la documentation Access chez Microsoft.
Les fichiers Microsoft Access sont des fichiers Office. Les fichiers Office doivent se trouver dans un « emplacement approuvé » ou avoir leur « contenu 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. La recherche d’emplacements approuvés se produit chaque fois que vous ouvrez un fichier de bureau. Nous l’appellerons approuvé/activé à partir d’ici. REMARQUE : 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.
En savoir plus sur les emplacements approuvés :
Les macros, fonctions et sous-éléments sont la façon dont vous implémentez une logique métier dans votre base de données Access. Il est important que vous compreniez l’étendue et la visibilité avant de commencer.
Les événements (comme cliquer sur un contrôle) sur les contrôles d’un formulaire (par exemple, boutons, zones de texte, étiquettes, etc.) déclenchent 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 Starter Edition utilise principalement des macros, et certains VBA où les macros ne sont pas en mesure d’effectuer les fonctions nécessaires. Northwind Developer Edition utilise principalement VBA.
Certains types de contrôle disposent d’Assistants intégrés pour créer 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 main façon dont vous affichez et accédez à 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 Northwind 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.
Il est important d’en savoir plus sur l’étendue et la visibilité dans Access/Office. Vous pouvez commencer ici :
Parfois, vous avez besoin qu’une variable existe après que l’objet qui l’a créée sort de l’étendue. Consultez Étendue et visibilité ci-dessus. Il existe trois méthodes principales pour effectuer cette opération : Variables publiques, TempVars et Stockage des valeurs dans une table locale. De nombreux développeurs utilisent une combinaison de ces éléments. Chacun a ses avantages et ses inconvénients. Plus d’informations sur chacun d’entre eux ici :
Variable publique du module VBA :
TempVars :
Stockage des valeurs dans la table locale
-
Les variables publiques et TempVars existent pour la session active et sortent de l’étendue lorsque l’application est fermée. Mais que se passe-t-il si vous souhaitez conserver des variables spécifiques à l’utilisateur entre les sessions ? Vous pouvez stocker ces types de valeurs dans une table locale. Dans Northwind 2.0, une variable de ce type est enregistrée dans une table appelée SystemSettings. La valeur de la table est ShowWelcome. Cette valeur indique à Access si vous souhaitez voir l’écran d’accueil chaque fois que vous vous connectez ou non.
Les développeurs doivent souvent passer des paramètres d’un formulaire à un autre, ou d’un formulaire à un rapport. Ces paramètres transmettent des informations importantes, que la fonction appelée utilisera ensuite pour se configurer elle-même. Il existe plusieurs façons pour le deuxième formulaire ou état d’obtenir des informations à partir du premier formulaire. Voici quelques-unes de ces façons :
-
Le deuxième formulaire peut « revenir » au premier formulaire pour récupérer des valeurs, éventuellement dans un contrôle visible ou invisible. Par exemple :
lngCustomerID = Forms!FirstForm!cboCustomerID -
Le premier formulaire peut enregistrer des valeurs dans des variables globales ou dans TempVars. Par exemple :
g_lngUserID = Me.cboUserID
TempVars.Add « UserID », Me.cboUserID
La méthode souvent utilisée dans Northwind Developer Edition ainsi que dans nos vies professionnelles consiste à utiliser l’argument OpenArgs de DoCmd.OpenForm ou OpenReport. Par exemple :
DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)
Nous combinons ici deux techniques : (1) l’utilisation d’OpenArgs pour passer les valeurs VendorID et VendorType, et (2) l’utilisation de la fonction StringFormat() pour créer, par exemple, cette chaîne :
CompanyID=5&CompanyTypeID=2
Cette chaîne ressemble beaucoup à une chaîne de requête telle qu’elle est utilisée dans un navigateur. Il contient une ou plusieurs « paires nom/valeur » séparées par le caractère esperluette :
name1=value1&name2=value2
L’avantage d’une telle chaîne est que chaque valeur a un nom. Comparez cela à une approche plus simple où vous définiriez OpenArgs uniquement sur « 5,2 ». Dans ce cas, il faudrait faire des efforts pour déterminer ce que signifie chaque valeur. Nommer chaque valeur rend la chaîne de requête « auto-décrivant », ce qui est une bonne pratique de programmation.
À l’extrémité de réception de DoCmd.OpenForm , nous sommes généralement dans l’événement Form_Open ou Form_Load et nous voulons analyser la chaîne OpenArgs dans ses composants.
Dans Northwind, vous pouvez le faire avec la fonction StringToDictionary . Il prend une fonction de type querystring et l’analyse dans ses composants. Ces composants sont ensuite stockés dans un objet Scripting.Dictionary . Notez que pour ce faire, vous devez utiliser Des outils > références et définir une référence à Microsoft Scripting Runtime (scrrun.dll).
Les fonctionnalités et avantages de l’objet Dictionary sont les suivants :
-
L’ordre des éléments n’est pas important
-
Fonctions simples pour ajouter et supprimer des éléments de la collection
-
Fonctions pour effectuer une boucle sur la collection, afin que vous puissiez savoir ce qu’elle contient
-
Fonction Exists permettant de tester si un élément spécifique est disponible
L’utilisation de l’objet dictionnaire apparaît dans Northwind. Par exemple, l’événement Form_Load dans frmGenericDialog.
Les macros créées avec les Assistants Contrôle dans Access incluent rarement la gestion des erreurs ; VBA créé avec les Assistants Contrôle peut être limité à un MsgBox Générique Err.Description.
Dans Northwind 2.0, nous vous montrons comment mieux faire avec du code VBA. 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 ici est que la gestion des erreurs est cohérente. Et si le message doit être modifié (par exemple, pour afficher le numéro d’erreur ou pour enregistrer l’erreur dans un fichier), il ne doit être effectué qu’à un seul endroit.
clsErrorHandler est le module de classe qui implémente le code de gestion des erreurs. Un module de classe conserve toutes ses fonctions main et d’assistance dans une unité, ce qui encapsule le code.
La macro AutoExec appelle la fonction Startup dans modStartup. Dans Starter Edition, la fonction crée une instance de clsErrorHandler et l’enregistre en tant que variable globale disponible pour une utilisation dans l’ensemble de l’application. Dans l’édition Dev, une classe statique est utilisée. Consultez les commentaires en haut du module de classe.
En fait, le code de gestion des erreurs dans les procédures est tellement cohérent que nous avons pu le créer en moins de cinq minutes à l’aide d’un code VBA spécifique qui a équipé chaque procédure du gestionnaire d’erreurs approprié. (Code non inclus dans le modèle). Les éditions de modèle Northwind 2.0 Starter et Developer ont été initialement dotées de cette approche de gestion des erreurs.
'
GESTION AMÉLIORÉE DES ERREURS
À compter de la version 2.2 de Northwind Developer Edition, le gestionnaire d’erreurs a été amélioré grâce aux commentaires de la communauté Access. L’édition de démarrage est inchangée.
En substance, le gestionnaire d’erreurs dans la version précédente (2.0 - publiée en avril 2023) est :
Public Sub HandleError(…)
MsgBox Err.Description
End Sub
Dans la version 2.2, elle est mise à niveau vers :
Public Sub HandleError (…, Optional ByVal IsEventProcedure As Boolean = False)
If Not IsEventProcedure Then
Err.Raise lngError, strErrSource
End If
MsgBox Err.Description
End Sub
Pour comprendre pourquoi cette modification a été apportée, commençons par comprendre ce qui rend le code exécuté :
-
La macro AutoExec appelle la procédure de démarrage, qui effectue certaines initialisations avant d’ouvrir le premier formulaire.
-
L’utilisateur interagit avec l’application, par exemple en ouvrant un formulaire ou en cliquant sur un bouton, ce qui provoque le déclenchement de procédures événementielles telles que Form_Load et cmdPrintInvoice_Click.
'
En plus des procédures événementielles, les applications ont des sous-routines et des fonctions, principalement dans les modules, et ce code est appelé à partir des procédures événementielles. Ces procédures sont appelées procédures « standard ».
Dans la version 2.0 de Northwind, les procédures standard géraient leurs propres erreurs avec les messages, mais elles n’informaient pas la procédure événementielle appelante qu’une erreur s’était produite. Cela peut être incorrect si la procédure événementielle a un code suivant qui doit s’exécuter indépendamment de l’erreur précédente gérée par la procédure appelée. Bien sûr, nous pourrions remplacer la sous-routine par une fonction qui retourne la réussite ou l’échec, et coder la procédure événementielle en conséquence, mais ce n’est pas toujours une option.
Dans Northwind version 2.2, les procédures standard ne gèrent pas les messages d’erreur, mais, à l’aide de Err.Raise, les signalent à la procédure événementielle appelante. La procédure événementielle appelant affiche ensuite l’erreur déclenchée et reprend à Exit_Handler. C’est mieux, car cela permet à la procédure appelante de se terminer correctement.
Pour utiliser le code Northwind version 2.2, les procédures événementielles doivent passer à HandleError un troisième argument indiquant que l’appelant est une procédure événementielle. Northwind Dev Edition a été mis à jour pour ce faire.
Un module de gestionnaire d’erreurs encore plus puissant prend en charge les procédures « pushing and popping » sur une « pile » (tableau). Le premier élément étant toujours la procédure événementielle, l’argument supplémentaire n’est pas nécessaire. Cette implémentation dépasse les objectifs de Northwind Dev Edition.
MRU, ou Most Recently Used est une liste de commandes et de bons de commande récemment utilisés. Vous souhaiterez peut-être revenir à ces éléments fréquemment pour les placer dans l’état suivant. Les listes mrU sont souvent considérées dans les produits Office sous la forme d’une liste de fichiers récemment utilisés que vous souhaiterez peut-être rouvrir.
Dans l’édition Northwind Dev, pour implémenter la fonctionnalité MRU (qui n’existe pas dans l’édition Starter), vous devez d’abord établir les éléments suivants :
-
Table pour stocker les informations d’utilisation des informations d’utilisation de l’information.
-
Code permettant de mettre à jour la table lorsqu’une commande ou un bon de commande (PO) est ouvert.
-
Code pour mettre à jour la liste déroulante MRU dans le ruban.
-
Code pour charger l’élément lorsqu’un élément MRU est sélectionné dans le ruban.
Examinons chacun d’entre eux plus en détail.
1. Table pour stocker les informations mrU.
La conception de la table MRU mérite d’être revue, en particulier ses index. Notez qu’il existe un index SortIdx en double pour faciliter le tri rapide des éléments MRU dans la liste déroulante du ruban, ainsi qu’un index unique pour appliquer la règle métier selon laquelle pour chaque utilisateur un élément ne peut se produire qu’une seule fois. Par exemple, l’ouverture de la même commande deux fois ne crée pas deux enregistrements dans la table MRU.
La table tire parti du fait que tous les champs PK (clé primaire) liés à MRU dans la base de données sont AutoNumber, de sorte que le type de données Integer long peut être utilisé pour PKValue.
2. Code pour mettre à jour la table lorsqu’une commande ou une P.O. est ouverte.
Dans NW2, nous avons choisi d’ajouter à la liste MRU uniquement lorsqu’un enregistrement a été créé, et non lorsqu’un enregistrement existant a été à nouveau mis à jour. Nous pourrions certainement déplacer l’appel AddToMRU de Form_AfterInsert à Form_AfterUpdate pour le prendre en charge.
Les procédures AddToMRU et DeleteFromMRU sont implémentées dans modGlobal, qui est un module standard dont les procédures publiques sont visibles sous n’importe quel formulaire.
AddToMRU (comme son nom l’indique) ajoute le nouvel élément à la table MRU, puis le supprime éventuellement, en supprimant l’enregistrement le plus ancien, s’il a dépassé la taille maximale (MAX_MRU_COUNT). La dernière étape est probablement la moins connue des développeurs Access : la liste déroulante du ruban doit être actualisée et cela s’effectue en appelant InvalidateControl. Il s’agit d’un signal pour que le ruban réexécute son processus d’initialisation.
3. Code pour mettre à jour la liste déroulante MRU dans le ruban.
Au moment du démarrage, et après l’appel d’InvalidateControl , un ensemble complexe de fonctions est exécuté pour remplir le ruban. Ces procédures sont appelées par le code XML du ruban dans la table uSysRibbons , qui indique en partie :
<group id="gCurrentStatus" label="MRU">
<box id="bxMRU" boxStyle="vertical">
<dropDown id="ddMRU"
getItemCount="ddMRU_GetItemCount"
getItemLabel="ddMRU_GetItemLabel"
getSelectedItemIndex="ddMRU_GetSelectedItemIndex"
getItemID="ddMRU_GetItemID"
onAction="ddMRU_OnAction"
screentip="Most Recently Used Objects">
</dropDown>
</box>
</group>Ces quatre fonctions de rappel remplissent la liste déroulante. Notez qu’il s’agit de la même idée que celle décrite ici pour les combobox standard.
Si vous supprimez les marques de commentaire des lignes Debug.Print dans modRibbonCallback et redémarrez l’application, la fenêtre Exécution présente une séquence semblable à celle-ci :
ddMRU_GetItemCount ddMRU 6
ddMRU_GetItemLabel ddMRU 0 Order 60, Proseware, Inc.
ddMRU_GetItemID ddMRU 0 2
ddMRU_GetItemLabel ddMRU 1 Order 62, Best For You Organics Company
ddMRU_GetItemID ddMRU 1 4
ddMRU_GetItemLabel ddMRU 2 Order 63, Wide World Importers
ddMRU_GetItemID ddMRU 2 5
ddMRU_GetItemLabel ddMRU 3 Order 66, Proseware, Inc.
ddMRU_GetItemID ddMRU 3 8
ddMRU_GetItemLabel ddMRU 4 Order 67, Best For You Organics Company
ddMRU_GetItemID ddMRU 4 9
ddMRU_GetItemLabel ddMRU 5 Order 68, Adatum Corporation
ddMRU_GetItemID ddMRU 5 10
ddMRU_GetSelectedItemIndex ddMRU 0
Nous pouvons voir ici qu’Access appelle d’abord une procédure qui retourne le nombre d’éléments à charger dans l’argument ByRef de ddMRU_GetItemCount. C’est également le moment où nous allons ouvrir la requête sur la table MRU et la mettre en cache, car elle est sur le point d’être utilisée plusieurs fois.
Le ruban appelle ensuite à plusieurs reprises deux procédures pour obtenir les valeurs ID et Label pour la liste déroulante à deux colonnes.
Enfin, il appelle une procédure pour dissocier l’élément à sélectionner. (Dans notre cas, il s’agit du premier.)
4. Code pour le chargement d’un élément lorsque l’élément MRU est sélectionné dans le ruban.
Comme pour tout autre élément du ruban, la propriété OnAction dans le code XML du ruban spécifie une fonction de rappel à utiliser pour effectuer l’action :
onAction="ddMRU_OnAction"
Cette procédure est implémentée dans modRibbonCallback. Il réutilit le jeu d’enregistrements déjà ouvert pour rechercher l’enregistrement avec l’élément sélectionné, puis, en fonction du TableName requis, ouvre le formulaire correspondant, en transmettant la valeur PK à charger.
-
Northwind 2.0 Developer Edition: Template-Tutorial
-
Northwind 2.0 Developer Edition : Toutes les rubriques
