Pour partager cette vidéo sur les réseaux sociaux ou sur un site, voici son url :
Sujets que vous pourriez aussi aimer :Contrôles et formulaires par onglets
Ce nouvel
exercice Access fait aussi office de
formation. Les notions que nous y abordons sont particulières mais essentielles. Dans l'exercice précédent, nous avons abouti le développement des deux
formulaires d'insertion. Le premier permet de créer un nouveau client tandis que le second permet de créer un nouveau produit. Pour mener à bien cette mise en oeuvre, nous avons conçu deux
requêtes Ajout dynamiques. Elles prélèvent les données à insérer depuis le formulaire, au moment de la demande.
Dans le cas d'une
navigation par onglets, le problème se corse. Le
formulaire en question n'est plus reconnu comme le formulaire parent. Il est encapsulé dans une navigation à étages. Pour l'atteindre, il faut raisonner hiérarchiquement en désignant les contrôles parents puis enfants, jusqu'à l'atteindre. Cela signifie que toutes les expressions de correspondance sont remises en cause. Et nous allons le constater.
Source et présentation de la problématique
Pour résoudre ce problème épineux, il est tout d'abord nécessaire de réceptionner l'application au dernier indice.
- Télécharger le fichier clients-et-commandes-controles-onglets.rar en cliquant sur ce lien,
- Le décompresser dans le dossier de votre choix,
- Puis, double cliquer sur le fichier résultant pour l'ouvrir dans Access,
- Dans la boîte de dialogue qui se déclenche, taper le mot de passe abc,
- Cliquer ensuite sur le bouton Activer le contenu du bandeau de sécurité,
- Enfin, saisir de nouveau le mot de passe abc,
La saisie du mot de passe n'est demandée qu'une seule fois à l'ouverture. Mais comme cette
base de données émane d'une source externe, il est nécessaire de l'activer, pour des raisons de sécurité. Cette activation regénère la base. C'est pourquoi, la boîte de dialogue est de nouveau déclenchée. A l'avenir, une seule saisie suffira.
- Dans le volet de navigation, double cliquer sur le formulaire F_creer_client pour l'ouvrir,
- A l'invite, taper le mot de passe administrateur suivant : abc123,
Dès lors l'accès au formulaire de création est déverrouillé.
- Renseigner toutes les informations demandées dans les champs,
- Puis, cliquer sur le bouton Créer Client,
Un message de confirmation apparaît. Il s'agit d'une
action de macro enclenchée juste après celle exécutant la
requête dynamique pour l'
insertion des données dans la table.
- Valider ce message de confirmation en cliquant sur son bouton,
- Dans le volet de navigation, double cliquer sur la table Clients pour l'ouvrir,
- Puis, atteindre la fin des enregistrements avec l'ascenseur vertical,
Comme vous pouvez le voir, le nouveau client est parfaitement ajouté à la suite des
enregistrements dans la
table source. Notre
formulaire fonctionne très bien, surtout s'il est exploité indépendamment. Mais ce n'est pas l'objectif de cette application. Tous les outils sont réunis sur une même interface, avec des
onglets de navigation. Et pour cause, ils sont nombreux. Et dans ce contexte, le comportement des liaisons et interactions est totalement remis en cause.
C'est la raison pour laquelle, l'enjeu de cette formation est particulièrement important. Ce système de navigation ne doit pas être contourné. Il apporte beaucoup de souplesse et de confort. Mais tout d'abord, nous proposons de constater le dysfonctionnement.
- Fermer la table Clients en cliquant sur la croix de son onglet,
- Puis, fermer le formulaire F_creer_client,
- Dans le volet de navigation, double cliquer sur le formulaire _F_navig_actions,
- A l'invite, saisir le mot de passe : abc123, pour déverrouiller l'accès,
Ce
formulaire regroupe plusieurs outils dans une
navigation verticale par onglets. Le
formulaire actif par défaut est le formulaire permettant de créer un client. Il s'agit précisément de celui que nous venons d'exploiter et dont nous avons pu attester le bon fonctionnement.
- Comme précédemment, renseigner toutes les informations demandées,
- Puis, cliquer sur le bouton Créer Client,
Bien qu'il s'agisse exactement du même
formulaire, mais encapsulé, cette fois le comportement est tout autre.
Access affiche une boîte de dialogue dans laquelle il demande précision. Ce n'était pas le cas précédemment. Il s'agit de l'expression de correspondance entre la
requête et le
formulaire pour prélever les données à insérer. Et dans ce premier message, la requête dynamique ne parvient plus à trouver l'information correspondant à la civilité.
Si vous cliquez sur le bouton Ok, les messages s'enchaînent. Le problème est strictement identique pour les autres champs. Dans ce contexte, le
formulaire creer_client est considéré comme un
sous formulaire du
formulaire de navigation. En conséquence, l'expression :
[Formulaires]![F_creer_client]![Civilite]
Ne suffit plus pour atteindre ces contrôles. Dans la hiérarchie, il faut construire une expression passant par le formulaire parent et descendant jusqu'au formulaire enfant.
Remarque : A l'issue des messages, vous obtenez une confirmation de la création du client. Mais il n'en est rien. Il s'agit d'une action de macro déclenchée sans test préalable.
Le souci rencontré est exactement le même avec le
formulaire F_creer_produit, qui fonctionne très bien indépendamment. Et le dysfonctionnement se corse un peu plus dans le formulaire de navigation à deux étages :
_F_navig_principal. Le niveau de profondeur à atteindre pour désigner les contrôles est encore plus important.
Notre base de données et de nombreuses applications professionnelles sont amenées à exploiter ces constructions par onglets. Elles sont fort précieuses et ne doivent pas être contournées. Nous devons donc apporter la solution dans les deux contextes.
Contrôles de sous-formulaire avec onglets
Dans un premier temps, nous proposons d'apporter la solution pour le cas le moins complexe. Il concerne le
premier formulaire offrant une navigation verticale de tous les outils destinés à agir sur les
tables. Il sera dès lors moins compliqué de trouver la parade pour l'instrument principal de cette application, celui du
formulaire de navigation offrant deux niveaux de profondeur.
Comme nous le disions, nous devons adapter les syntaxes des expressions de correspondance dans les
requêtes Ajout, exécutées au clic sur les boutons. Pour atteindre le contrôle par le générateur d'expression, il s'agit de passer tout d'abord par le formulaire parent.
- Fermer toutes les tables et formulaires ouverts,
- Dans le volet de navigation, déployer la catégorie des requêtes,
- Avec la touche CTRL enfoncée, cliquer sur les requêtes R_creer_client et R_creer_produit,
Ainsi, nous les regroupons dans une même sélection.
- Les copier par le raccourci clavier CTRL + C par exemple,
- Puis, les coller par le raccourci clavier CTRL + V,
Une boîte de dialogue se déclenche proposant de nommer la copie.
- Accepter les noms proposés par défaut en validant par Ok,
Ainsi, nous conservons une requête dynamique fonctionnelle pour les formulaires fonctionnant indépendamment.
- Dans le volet de navigation, cliquer droit sur la requête R_creer_client,
- Dans le menu contextuel, choisir Mode création,
Nous basculons ainsi dans l'éditeur de requêtes et pouvons consulter les expressions précédemment construites pour les champs respectifs.
- Cliquer droit dans la zone Champ de la première colonne (Client_civilite),
- Dans le menu contextuel, choisir Créer,
Nous affichons ainsi la syntaxe de correspondance dans le
générateur d'expression :
Expr1:[Formulaires]![F_creer_client]![Civilite]
Telle qu'elle est conçue à ce stade, elle considère le
formulaire F_creer_client comme le formulaire principal. Mais dans ce nouveau contexte, il est encapsulé dans le
formulaire de navigation _F_navig_actions.
- Sélectionner toute l'expression par le raccourci clavier CTRL + A par exemple,
- Puis, la supprimer afin de la reconstruire complètement,
- Dans la liste de gauche, déployer l'arborescence des formulaires jusqu'à sélectionner le formulaire _F_navig_actions,
- Dans la liste du centre, double cliquer sur l'élément SousFormulaireNavigation,
Le début de la syntaxe apparaît ainsi dans la partie supérieure du
générateur d'expression. Grâce à cet élément, nous accédons dans le
sous-formulaire du
formulaire de navigation.
- Dans la partie supérieure du générateur, cliquer à la fin de l'expression,
- Supprimer l'espace s'il existe,
En effet, la suite de la syntaxe doit être collée. Nous devons appeler les objets enfants.
- Taper le symbole du point (.),
Cette action a pour effet de déclencher l'affichage d'une liste. Elle propose tous les objets, propriétés et méthodes associés à ce sous-formulaire.
- Dans la liste, double cliquer sur l'élément Formulaire,
Nous référençons ainsi l'
objet Formulaire à la suite dans la syntaxe. C'est lui, depuis le sous-formulaire, qui permet d'atteindre les contrôles dépendants. Fort logiquement, il apparaît inscrit entre crochets.
- A la suite de la syntaxe, taper un point d'exclamation (!),
- Puis, saisir le nom du contrôle à atteindre entre crochets, soit [Civilite] ,
- Cliquer alors sur le bouton Ok du générateur d'expression,
La syntaxe validée apparaît désormais dans la zone Champ de la première colonne :
Formulaires![ _F_navig_actions]![SousFormulaireNavigation].[Formulaire]![Civilite]
Désormais, il s'agit d'adapter l'expression de correspondance dans les autres colonnes. La technique du copier-coller est conseillée. Seul le nom du contrôle à atteindre doit être ajusté en suffixe de la syntaxe.
Pour le champ Client_nom :
Expr2:Formulaires![ _F_navig_actions]![SousFormulaireNavigation].[Formulaire]![Nom]
Pour le champ Client_prenom :
Expr3:Formulaires![ _F_navig_actions]![SousFormulaireNavigation].[Formulaire]![Prenom]
Pour le champ Client_dep :
Expr4:Formulaires![ _F_navig_actions]![SousFormulaireNavigation].[Formulaire]![CP]
Pour le champ Client_ville :
Expr5:Formulaires![ _F_navig_actions]![SousFormulaireNavigation].[Formulaire]![Ville]
- Enregistrer ensuite les modifications de la requête (CTRL + S),
- Puis, la fermer en cliquant sur la croix de son onglet,
- Dans le volet de navigation, double cliquer sur le formulaire _F_navig_actions,
- A l'invite, saisir le mot de passe administrateur : abc123,
- Renseigner toutes les informations requises pour un nouveau client,
- Puis, cliquer sur le bouton Créer Client,
Cette fois, seul le message final apparaît. La requête semble avoir réussi à établir la liaison avec les contrôles du formulaire encapsulé. Et si vous ouvrez la
table Clients, vous constatez en effet la présence du nouvel enregistrement.
- Fermer le formulaire _F_navig_actions,
- Puis, double cliquer sur le formulaire _F_navig_principal pour l'ouvrir,
- Cliquer sur son dernier onglet Outils actions,
- Taper le mot de passe administrateur : abc123,
- Renseigner toutes les informations d'un nouveau client,
- Puis, cliquer sur le bouton Créer Client,
Malgré nos adaptations, le même problème que précédemment se pose. La correspondance avec les contrôles n'est pas trouvée. Et c'est tout à fait naturel. Bien qu'il s'agisse du même formulaire de création, il est encapsulé dans une
double navigation à onglets.
Ce
formulaire à étages est l'outil principal de notre application. C'est lui que nous devons rendre fonctionnel. Et il s'agit d'adapter les deux requêtes cette fois :
R_creer_client et
R_creer_produit.
Remarque : Des règles de validité ont été posées sur les tables à l'occasion d'exercices. Elles contrôlent notamment la longueur des informations renseignées. Si vous ne visualisez pas le nouvel enregistrement, cela implique que certaines saisies sont insuffisantes, comme une ville sur 3 lettres par exemple.
Contrôles de sous-formulaires en cascade
Bien que nous ne la validions pas ici, l'étape précédente était importante. Tout d'abord, elle démontre comment
atteindre les contrôles d'un formulaire encapsulé dans un
formulaire de navigation. De plus, elle fournit la démarche à suivre. Pour atteindre le contrôle cible dans l'expression de correspondance, il faut descendre hiérarchiquement tous les objets l'encapsulant.
- Fermer le formulaire _F_navig_principal,
- Dans le volet de navigation, cliquer droit sur la requête R_creer_client,
- Puis, dans le menu contextuel, choisir Mode création,
Nous sommes ainsi de retour dans l'
éditeur de requête Access.
- Cliquer droit dans la zone Champ de la première colonne (Client_civilite),
- Dans le menu contextuel, choisir Créer pour afficher le générateur d'expression,
- Sélectionner la syntaxe complète (CTRL + A), puis la supprimer,
- Dans la liste de gauche, déployer l'arborescence des formulaires jusqu'à sélectionner le formulaire _F_navig_principal,
- Dans la liste du centre, double cliquer sur l'élement : SousFormulaireNavigation,
Ainsi et comme précédemment, nous inscrivons le début de la syntaxe dans la partie supérieure du
générateur d'expression :
Formulaires![_F_navig_principal]![SousFormulaireNavigation].
- Cliquer à la fin de l'expression et supprimer l'espace éventuel,
- Taper le symbole du point (.),
- Puis dans la liste, double cliquer sur l'élément Formulaire pour l'ajouter,
- Taper un point d'exclamation (!),
- Puis, désigner le sous formulaire suivant : [SousFormulaireNavigation],
Il est conseillé de réaliser un copier-coller pour répliquer le précédent, fourni par le
générateur d'expression.
- Taper de nouveau un point (.),
- Désigner l'élément [Formulaire] par copier-coller idéalement,
- Enfin, taper un point d'exclamation suivi du nom du contrôle : ![Civilite],
- Enfin, valider la syntaxe en cliquant sur le bouton Ok du générateur d'expression,
Elle est fort naturellement plus complexe du fait du niveau de profondeur plus avancé. De plus, à partir d'un certain stade, les aides du générateur ne se déclenchent plus. L'expression de correspondance pour le
champ Client_civilite avec son contrôle dans le
formulaire à deux étages, est la suivante :
Expr1:[Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![Civilite]
Comme précédemment, il convient d'adapter l'expression des quatre autres colonnes, en conservant le nom du contrôle de destination en suffixe.
Pour le champ Client_nom :
Expr2:[Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![Nom]
Pour le champ Client_prenom :
Expr3: [Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![Prenom]
Pour le champ Client_dep :
Expr4:[Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![CP]
Pour le champ Client_ville :
Expr5:[Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![Ville]
- Enregistrer les modifications de la requête et la fermer,
- Double cliquer de nouveau sur le formulaire _F_navig_principal pour l'exécuter,
- Cliquer sur son dernier onglet Outils actions,
- Saisir le mot de passe administrateur : abc123,
- Renseigner toutes les informations d'un nouveau client,
- Puis, cliquer sur le bouton Créer Client,
Le message de confirmation de la
macro apparaît aussitôt. Plus aucune erreur n'est remontée. Il semblerait donc, malgré le niveau de profondeur des formulaires à onglets imbriqués, que nous ayons réussi à construire les expressions de correspondance dynamiques, permettant d'
atteindre les contrôles du formulaire le plus éloigné.
Si vous ouvrez la
table Clients, vous constatez en effet la présence du nouvel enregistrement ainsi créé.
Bien sûr, il convient ensuite d'adapter l'expression de correspondance des 6 colonnes pour la
requête R_creer_produit. Il suffit simplement de dupliquer tout le début de la syntaxe et de conserver le nom du contrôle à atteindre. Par exemple, pour la première correspondance :
Expr1:[Formulaires]![_F_navig_principal]![SousFormulaireNavigation].[Formulaire]![SousFormulaireNavigation].[Formulaire]![Reference]
Grâce à ces précieuses solutions pour atteindre en profondeur les contrôles de formulaires, nous pourrons poursuivre le développement de notre application, articulée autour des ces
formulaires de navigation par onglets.