Temps nécessaire pour suivre cette leçon : Entre trois quarts d'heure et une heure et quart
Pour suivre cette leçon, vous devez avoir suivi les leçons précédentes. Ou plus précisément, vous devez être en possession de la base de données ProFormation.mdb telle qu'elle était à la fin de la leçon précédente. Si vous n'êtes pas certain de l'avoir, vous pouvez la télécharger ici
Jusque-là, nous n'avons parlé que de stockage de données, mais pas tellement de convivialité... Effectivement, si tout restait comme ça, ce serait drôlement compliqué à remplir. Heureusement, nous avons un outil-de-la-mort : Le sous-formulaire, qui va permettre très aisément de saisir les données dans deux tables à la fois ! |
Eh bien, c'est enfin le moment d'aborder le sujet. Pour vous donner une idée de ce que sera le résultat final, le voici, sans fioritures :
Le principe est simple : Dans la partie de gauche, vous avec le formulaire principal : Il s'agit d'un formulaire en mode Colonne (Je vous conseille de réviser la leçon 29 pour vous remémorer la différence entre un formulaire en mode Colonne et en mode Tableau). Cette partie de gauche est en fait un formulaire tout simple, basé sur T_Cours. Nous ne voyons d'ailleurs que les détails du Cours numéro 1. La partie de droite est constituée par ce fameux sous formulaire : C'est en fait un formulaire en mode Tableau qui est incrusté dans le formulaire principal, mais qui possède l'indispensable particularité de n'afficher QUE les élèves du cours numéro 1, car il s'agit dans la partie de droite du cours numéro 1. Le sous-formulaire est donc dépendant au niveau de l'IDCours de son formulaire principal. Il y a donc bien 2 formulaires bien distincts, mais dans ce contexte, l'un est incrusté dans l'autre, ce qui lui confère l'appellation de sous-formulaire. Vous l'aurez compris : Inutile d'essayer de rêver à songer d'imaginer un formulaire avec sous-formulaire si la structure sous-jacente des tables n'est pas parfaitement comprise et appliquée, ce qui explique pourquoi vous avez fait tant de leçons avant d'en arriver là.
Avant de commencer, je vous conseille peut-être de réviser les leçons sur les formulaires, afin de ne pas devoir réfléchir sur des choses qui sont normalement acquises. Je pense aux leçons 29, 30 et 31 surtout.
Bien. Pour commencer, vous allez créer un nouveau formulaire, basé sur T_Cours, qui va avoir a peu près cette apparence : . Vous l'enregistrerez sous F_Cours, et vous le fermerez.
Maintenant, tout à fait indépendamment, vous allez créer, avec le formulaire assistant tableau, un formulaire basé sur T_Eleve, qui va ressemble à ceci en mode création : , et à ceci en mode saisie de données : . Vous l'Enregistrez sous F_EleveSF (SF = Sous-Formulaire, ce n'est pas obligatoire d'écrire SF, mais c'est plus facile), et vous le fermez.
Actuellement, vous avez donc à disposition deux formulaires distincts, qui fonctionnent parfaitement l'un sans l'autre, il n'y a actuellement aucune interaction entre eux : F_Cours liste les cours, un cours par écran, F_Eleve liste les élèves et leur numéro de cours, plusieurs enregistrements par écran, tout bêtement. Jusque-là, rien de magique, donc.
C'est ça. Ouvrez F_Cours en mode création. Affichez la boîte à outils (Affichage/Boîte à outils). Cliquez sur la baguette magique de manière à ce qu'elle ne donne pas l'impression d'être enfoncée : Cette baguette magique est l'interrupteur de l'assistant. C'est à dire que si cette baguette magique est enfoncée, quand vous allez installer le sous formulaire, un assistant vous permettant de le mettre en place correctement va apparaître. On pourrait trouver ça très bien, mais en fait, j'ai constaté que cet assistant n'était pas très pratique à utiliser, mais cet avis n'engage que moi. D'autre part, en faisant l'opération manuellement, on comprend mieux ce qu'on fait.
Cliquez sur le contrôle sous-formulaire de la boîte à outils : , et dessinez un grand rectangle sur le côté, comme ceci : . C'est la zone d'accueil du sous formulaire. Pour l'instant, il est vide : Si vous lancez votre formulaire en mode saisie de données, vous ne verrez qu'un rectangle blanc, avec un petit texte "Fille7" au dessus, c'est son petit nom, il n'est pas important. Vous pouvez carrément effacer cette petite étiquette Fille7.
C'est juste maintenant que la magie va opérer : Nous allons préciser à Access que ce sous formulaire va contenir en fait le formulaire en mode tableau F_EleveSF.
Pour ce faire, en mode création, demandez les propriétés de ce grand rectangle blanc (Bouton droit/propriétés). Dans l'onglet Donnée, il y a 3 propriétés qui vons nous intéresser : Objet source, Champ père et Champ fils : . Constatez que les 3 propriétés sont actuellement vides. Choisissez F_EleveSF dans ObjetSource, et regardez : Instantanément, le champ père et le champ fils contiennent IDCours : . Nous allons revenir à ces fameux champs père/champ fils. Pour l'instant, nous allons simplement constater que ça marche : Lancez votre formulaire en mode saisie de données : . C'est exactement le résultat promis en début de leçon. Ce qu'il faut bien constater, c'est que votre formulaire F_EleveSF n'est pas complet. S'il était complet, il contiendrait tous les élèves de tous les cours, comme ceci : . Or, quand il est en sous-formulaire, il ne contient QUE les élèves du cours numéro 1. En fait, il ne contient que les élèves qui font partie du cours qui est précisé dans le formulaire principal F_Cours. Déplacez vous sur le cours numéro 2 : . Vous constatez qu'effectivement, le sous-formulaire ne contient plus maintenant exactement que les élèves du cours numéro 2. C'est ça le fameux Champ père/Champ fils . En fait, le champ père est l'IDCours de la table T_Cours, et donc du formulaire F_Cours, et le champ fils s'appelle aussi IDCours, mais c'est celui de T_Eleve cette fois. Faisons un test amusant : Revenez en mode création.
ATTENTION : avec Access 2000, vous continuerez à voir le sous formulaire correctement : , mais avec Access 97, vous ne verrez qu'un rectangle blanc : C'est normal... D'ailleurs, même avec Access 2000, il est des cas ou quand vous revenez en mode création, vous ne voyez aussi qu'un rectangle blanc à la place du sous formulaire : Il suffit de le RElancer en mode saisie de données, et encore le remettre en mode création, et vous le verrez normalement.
Nous allons donc faire un test amusant : allez dans les propriétés du sous formulaire. Attention encore, ne cliquez pas deux fois sur le sous formulaire en mode création, car dans le cas ou vous avez access 2000, c'est carrément le sous formulaire qui va s'activer (exactement comme les graphiques à la leçon 55), et dans le cas d'Access 97, il va carrément s'ouvrir devant l'autre, dans une nouvelle fenêtre.
En fait, c'est vachement délicat : Je m'afresse ici aux utilisateurs d'Access 2000 : en mode création :
- Si vous ne cliquez pas sur le sous formulaire, il ressemble à ça : (rien à signaler)
- Si vous cliquez une fois sur le sous formulaire, c'est la zone d'accueil du sous-formulaire qui est sélectionnée : . Il y a des carrés noirs de redimensionnement qui apparaissent
- Et si vous recliquez encore une fois sur ce sous formulaire, il apparait comme ceci : le petit carré noir dans le coin qui indique que c'est carrément le formulaire en tant que tel qui est sélectionné.
Dans notre cas, pour faire l'expérience amusante que je vous proposais, il s'agit de demander les propriétés de la zone d'accueil du sous formulaire : . Et dans l'onglet Données, effacez le champ père et le champ fils : . Relancez votre formulaire en mode saisie de données : . Vous constatez que cette fois, le sous formulaire affiche la totalité de la table T_Eleve, même si nous sommes dans la partie de gauche sur le numéro 1. Dans ce cas, c'est simplement un formulaire qui à été incrusté dans un autre, sans lien.
Remettez maintenant le champ père et fils à IDCours : , et tout rentre dans l'ordre.
Voici un schéma récapitulatif sur par exemple le cours numéro 3 :
Ca veut dire que c'est très bien fait ! En fait, cette ligne n'existe pas encore - comme dans les tables, la dernière ligne n'est pas une vraie ligne, c'est juste un espace pour écrire. Eh bien ici, c'est pareil, sauf que grâce à cette histoire de champ père champ fils, Access à l'extrême bon goût de déjà nous indiquer que le prochain élève fera partie du numéro 3. On le sait que c'est le numéro 3, puisque dans F_Cours, c'est ce qui est écrit, mais je vous rappelle quand même qu'il est indispensable de répéter ce numéro dans la table T_Eleve pour faire la liaison... Alors, on dit Merci Access !
Faison un test. Pour le cours numéro 3, il y a Maria Potache qui s'inscrit. Ajoutez-là, et surtout, à l'instant ou vous écrivez la première lettre P de Potache, remarquez qu'une nouvelle ligne apparait pour encore ajouter quelqu'un , et ceci jusqu'à l'infini... Terminez le nom : .
Exactement. regardez la table : . Revenez dans votre formulaire ensuite.
Il va se laisser faire. Mais quand vous allez changer d'enregistrement, par exemple vous placer sur le cours numéro 4, et revenir sur le 3, vous aurez la surprise de voir que Maria Potache à disparu! Eh oui, c'est normal, parce que le champ père champ fils, ce n'est pas bien compliqué : En numéro 3, il voit 3 personnes, il les affiche, point. Et par contre, dans la même logique, si vous vous posistionnez sur le premier cours, vous allez constater que Maria Potache est maintenant inscrite au cours 1 : .
Effectivement, vous avez saisi : Si vous essayez d'entrer des élèves alors que le cours n'a pas de numéro, ça va très mal se passer. Vous pouvez essayer pour voir ce que ça fait, et ensuite aller voir dans les tables ce qui s'est passé. Comme vous voulez...
Ah ben si... On pourrait bloquer le champ IDCours de T_Eleve (Activé = Non, verrouillé = Oui : C'était à la leçon 37)
Essayons. En mode création, les utilisateurs d'Access 2000 n'auront pas rop de difficultés à effacer IDCours et son étiquette, mais les utilisateurs d'Access 97 devront cliquer deux fois sur la zone d'accueil du sous-formulaire pour l'activer, et ensuite fermer le formulaire F_EleveSF pour revenir à F_Cours.
Bref, dans un cas comme dans l'autre, effacez l'étiquette et le champ IDCours de manière à avoir cet affichage : . Constatez qu'il ne s'est pas mélangé les pinceaux : En l'occurrence, je suis toujours sur le cours numéro 1 : Il ne m'affiche toujours que les élèves du cours numéro 1 : Donc ça marche.
Essayons : . Mais si vous essayez de Enregistrez votre enregistrement avec SHIFT ENTER, ou que vous essayez simplement de changer d'enregistrement, ce qui revient au même, vous aurez peut-être ce message : . Ce qui veut dire qu'à cause (ou grâce à) l'intégrité référentielle, il n'est pas d'accord : Il essaye d'ajouter un nouvel enregistrement dans T_Eleve par l'intermédiaire de F_EleveSF, mais comme nous avons effacé IDCours (du formulaire, pas de la table), Access ne peut plus recopier IDCours de F_Cours pour l'injecter dans IDCours de F_EleveSF... D'ou l'erreur. J'ai dit que vous aurez peut-être ce message, car il arrive pour des raisons que j'ignore, que ça marche, et que malgré le fait que IDCours soit effacé du sous formulaire, il arrive quand même à le remplir, mais je ne sais pas pourquoi. Nous n'allons donc pas l'effacer.
Vous allez le remettre en place (en le faisant glisser depuis la liste des champs) : attention, parce que comme vous n'avez pas beaucoup de place pour le poser, je vous conseille la manière suivante :
Nous voici comme avant. Donc, nous n'allons pas simplement effacer IDCours de F_EleveSF, mais le rendre invisible. Demandez les propriétés d'IDCours, et dans l'onglet Format, choisissez Visible : Non : . Le champ reste visible en mode création, mais disparait en mode saisie de données. Essayez maintenant d'ajouter Kevin Cankre dans le cours numéro 1 : . Cette fois ça marche : Vous pouvez l'enregistrer. Et dans a table T_Eleve, vous constaterez qu'il est effectivement présent pour le cours numéro 1 : . Maintenant, vous pouvez juste pour des questions esthétiques supprimer la petite étiquette IDCours, et repousser vers la gauche les élèves : Mais comme en mode création, IDEleve est toujours bien visible, ce que vous allez faire, c'est réduire sa taille à presque rien, comme ceci : , ou même carrément le réduire tout petit petit jusqu'à ce ne soit plus qu'un petit point noir, et en plus le mettre tout discret dans le coin, comme ça : . Ca fait qu'il est toujours là, mais il est ivisible en mode saisie de données, et maintenant, même en mode création, il est vraiment hyper discret, mais on sait qu'il est là. Ce cas de figure arrive assez fréquemment (qu'on doive masquer le plus possible un champ, mais qu'il doive être présent pour des questions techniques). Et maintenant, on supprime l'étiquette, et on repousse vers la gauche l'étiquette et le champ IdentiteEleve : . Et on réduit la grille : .
Vous voià avec un formulaire et sous formulaire tout beau et tout convivial :
Nous allons nous arrêter là pour cette leçon vous pouvez tout fermer.
Qui dit "Un objet qui a un certain nombre de
sous-objets" dit "Deux tables" et dit par conséquent
"Formulaire avec sous formulaire". Le sous formulaire est un outil
terriblement efficace pour entrer les données dans deux tables "A
la fois". Effectivement, quand on saisit les données dans un
formualire avce sous formulaire, on a vraiment l'impression qu'on est dans
une seule table. Le formualire principal est toujours en mode Colonne (un enregistrement par écran), tandis que le sous formulaire est quasiment toujours en mode tableau (plusieurs enregistrement par écran, ligne par ligne). C'est ce qu'on a vu : Nous ne voyons d'un seul coup d'oeil qu'un seul cours, mais nous voyens en même temps tous les élèves de ce cours. Le sous-formulaire n'est d'ailleurs rien d'autre qu'un formulaire tout bête en mode tableau que nous incrustons dans un autre formulaire avec l'icône Sous-formulaire/sous-état que nous trouvons dans la boîte à outils des formulaires. Il est bien endendu qu'il est exclu de créer des sous formulaires si la structure des tables n'est pas parfaitement cofhérentes : La plupart du temps il faut qu'il y ait une relation avec intégrité référentielle entre la table principale qui va servir de base au formualire principal, et la sous-table qui va servir de base au sous formulaire. Le schéma est toujours le même à de très rares exceptions près : Un objet X contient des sous objets Y : La table qui contient les X sera à la base du formulaire principal, et la sous table des Y sera la base du sous formulaire. Une fois que vous avez compris ça, vous avez compris pas mal de choses. |
Pour voir les solutions, il vous suffit de sélectionner le questionnaire ci-dessus : 3 petites étoiles *** apparaîtront en face des bonnes réponses. |
L'exercice consiste à reprendre les deux bases de données de l'exercice de la leçon précédente : Critique.mdb, et ViveLamour.mdb. Vous allez simplement créer, pour chacune des deux bases de données un formulaire avec sous formulaire. Le formulaire avec sous formulaire de Critique.mdb devra ressembler à ça : Et le formulaire avec sous formulaire de ViveLamour.mdb devra ressemble à ça (ne vous fiez pas au titre de la fenêtre T_Candidat, c'est bien un formulaire...): |
Si vous n'êtes pas tout à fait certain d'avoir suivi correctement toutes les étapes de cette leçon, vous avez la possibilité de télécharger ici la version de ProFormation.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.
Avez-vous une question technique
concernant cette leçon ? Cliquez
ici !
Une remarque sur cette leçon ? Un problème
? Une erreur ? une ambiguité ? Soyez
gentil de m'en informer