Sommaire
- Démonstration théorique des sous-formulaires
- Création indépendante d'un formulaire qui servie de sous-forumulaire
- Incrustation d'un sous formulaire dans un formulaire
- Gestion de la liaison des données entre le sous-formulaire et le formulaire principal : Champ père et chanp fils
- Amélioration de l'aspect des sous-formulaires avec Access 2000
- Subtilités de sélection du sous-formulaire
- Schéma récapitulatif de l'utilisation d'un sous-formulaire
- Pré-détermination du champ fils dans le sous-formulaire
- Erreur : Testons un changement de champ-fils intempestivement
- Fonctionnement du sous-formulaire lors de la création d'un nouvel enregistrement dans le formulaire principal
- Dangers liés au changement possible des données du champ fils
- Il devient impossible d'utiliser le sous-formulaire comme un formulaire indépendant
- Astuce : Masquer le champ fils pour éviter les confusions et les erreurs de saisie
- Visualisation d'un sous-formulaire imbriqué dans un formulaire principal de manière conviviale
Enfin ! Depuis le temps que j'en entend parler de ces sous-formulaires !
Démonstration théorique des sous-formulaires
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à.
Compris. Alors, commente ça se passe, concrètement ?
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 et31 surtout.OK. Je me suis rafraîchi la mémoire, allons-y !
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.Création indépendante d'un formulaire qui servie de sous-forumulaire
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.
Mais maintenant, on va incruster F_Eleve dans F_Cours, c'est ça ?
Incrustation d'un sous formulaire dans un formulaire
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.
Gestion de la liaison des données entre le sous-formulaire et le formulaire principal : Champ père et chanp fils
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.Amélioration de l'aspect des sous-formulaires avec Access 2000
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.
Subtilités de sélection du sous-formulaire
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.Schéma récapitulatif de l'utilisation d'un sous-formulaire
Voici un schéma récapitulatif sur par exemple le cours numéro 3 :
Pré-détermination du champ fils dans le sous-formulaire
Alors là, je vois qu'en dessous de Jacques Bondernier, il y a une place vide, mais il y a déjà le numéro 3 
, qu'est ce que ça veut dire ?
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 : 
.Et dans la table T_Eleve, elle s'est rajoutée au numéro 3 ?
Exactement. regardez la table :
. Revenez dans votre formulaire ensuite.Erreur : Testons un changement de champ-fils intempestivement
Et qu'est-ce qui se passe si dans le cours numéro 3, je change le 3 de Potache Maria en 1 par exemple, comme ceci : 
?
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 : 
.Fonctionnement du sous-formulaire lors de la création d'un nouvel enregistrement dans le formulaire principal
Et comment est-ce que ça se passe quand je suis sur un NOUVEAU cours ?
Très simplement. Déplacez-vous sur un nouveau cours :
. Vous constatez qu'effectivement, il n'y a pas encore de numéro de cours : (NuméroAuto) dans F_Cours et carrément rien dans le sous formulaire. Admettons que vous voulions créer un cours de PowerPoint. Nous allons donc écrire PowerPoint dans NomCours. A l'instant précis ou vous allez commencer à écrire le P de Powerpoint dans NomCours, (NuméroAuto) va se transformer en 5 (Qui est le numéro logique de ce nouveau cours) et, à peu près une demie-seconde plus tard, ce 5 va être recopié dans IDCours du sous-formulaire : 
. Terminez d'entrer les données de ce cours PowerPoint : 
.C'est vraiment très cool ! Et donc, je suis en train d'y penser, on ne peut pas commencer à écrire les élèves sans que le cours ne soit rempli, ou en tout cas pas tant qu'il n'y a pas de numéro attribué à ce cours
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...Dangers liés au changement possible des données du champ fils
OK. Je reviens juste à ce qu'on disait tout à l'heure : Si on change un IDCours dans F_EleveSF, cet élève se verra tout à coup inscrit dans un autre cours.... C'est pas un peu dangereux, ça ?
Ah ben si... On pourrait bloquer le champ IDCours de T_Eleve (Activé = Non, verrouillé = Oui : C'était à la leçon 37)Ou alors... ne pourrait-on pas carrément l'effacer du sous-formulaire ? Comme ça, y'a plus de doutes...
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.Il devient impossible d'utiliser le sous-formulaire comme un formulaire indépendant
D'accord : Mais, est-ce que si j'ajoute un nouvel élève à un cours existant, par exemple j'ajoute Kevin Cankre à ce cours, va-t-il bien se comporter ?
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.Astuce : Masquer le champ fils pour éviter les confusions et les erreurs de saisie
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 :- Faites glisser le champ IDCours dans le pied de formulaire :
- Coupez-collez l'étiquette IDCours dans l'en-tête de formulaire :
- Réduisez le champ IDCours de manière à ce qu'il rentre à côté de IdentiteEleve :
- Faites glisser à la souris le champ IDCours dans le Détail, à côté de IdentiteEleve :
- Et enfin, réduisez le pied de formulaire (la grille) :
. 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 : 
.Visualisation d'un sous-formulaire imbriqué dans un formulaire principal de manière conviviale
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.
Bon... Hem... On peut résumer ?
| 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. |
Avez-vous bien compris ?
|
Exercice
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 :  |
0 commentaires:
Enregistrer un commentaire