Leçon 58 : Les sous-formulaires : création, intégration, Champ père/champ fils, modes d'affichage, propriété visible et masquage des champs

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

Aperçu de cette leçon

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 !

Sommaire

  1. Démonstration théorique des sous-formulaires
  2. Création indépendante d'un formulaire qui servie de sous-forumulaire
  3. Incrustation d'un sous formulaire dans un formulaire
  4. Gestion de la liaison des données entre le sous-formulaire et le formulaire principal : Champ père et chanp fils
  5. Amélioration de l'aspect des sous-formulaires avec Access 2000
  6. Subtilités de sélection du sous-formulaire
  7. Schéma récapitulatif de l'utilisation d'un sous-formulaire
  8. Pré-détermination du champ fils dans le sous-formulaire
  9. Erreur : Testons un changement de champ-fils intempestivement
  10. Fonctionnement du sous-formulaire lors de la création d'un nouvel enregistrement dans le formulaire principal
  11. Dangers liés au changement possible des données du champ fils
  12. Il devient impossible d'utiliser le sous-formulaire comme un formulaire indépendant
  13. Astuce : Masquer le champ fils pour éviter les confusions et les erreurs de saisie
  14. 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 et 31 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 :

  1. Faites glisser le champ IDCours dans le pied de formulaire :
  2. Coupez-collez l'étiquette IDCours dans l'en-tête de formulaire :
  3. Réduisez le champ IDCours de manière à ce qu'il rentre à côté de IdentiteEleve :
  4. Faites glisser à la souris le champ IDCours dans le Détail, à côté de IdentiteEleve :
  5. Et enfin, réduisez le pied de formulaire (la grille) :

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 : .


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 ?

  1. Un sous-formulaire peut se placer dans :
    a. Un formulaire ***
    b. Une table
    c. Une requête
    d.
    Un état

  2. Est- il possible d'ouvrir un sous-formulaire directement sans avoir besoin de l'ouvrir dans son formulaire "père"
    a. Oui, puisque c'est un banal formulaire ***
    b. Non, il fat partie intégrante de son formulaire "père"

  3. A quoi servent les notions de champ père / champ fils
    a. C'est une notion utilisée dans les relations avec intégrité référentielle. Le fait d'appliquer l'option "Effacer les enregistrements en cascade" implique que les champs en relation deviennent maintenant Père et Fils
    b.Ils servent à établir le lien entre le formulaire principal et le sous formulaire, afin d'éviter que le sous formulaire n'affiche tous les enregistrements de la table dont il est issu, mais seulement ceux qui correspondent au champ père du formulaire principal ***
    c. Le champ père est le champ le plus important du formulaire principal (Ici, le nom du cours). Les champs fils sont tous les autres champs du formulaire principal : L'identite du prof, la date du cours,m ses horaires et son prix
    d. Les champs pères et fils n'existent que dans Access 2000 : C'est un simple vocabulaire qui remplace la notion de relation avec intégrité référentielle

  4. Est-il possible dans un formulaire principal, d'avoir plusieurs sous formulaires ?
    a. Sûrement pas
    b. Je n'ai pas essayé, mais je pense que oui ***
    c. On est obligé d'avoir au moins 3 sous-formulaires

  5. Les formulaires avec sous-formulaires se présentent la plupart du temps sous cette forme :
    a. Formulaire principal : Mode colonne, sous formulaire : Mode Colonne
    b. Formulaire principal : Mode colonne, sous formulaire : Mode Tableau ***
    c. Formulaire principal : Mode Tableau, sous formulaire : Mode Colonne
    d. Formulaire principal : Mode Tableau, sous formulaire : Mode Tableau

  6. Pourquoi avons-nous à tout prix essayé de masquer IDCours dans le sous formulaire F_EleveSF ?
    a. Simplement pour montrer que c'est possible
    b. Parce que ça ne sert à rien de voir ce numéro puisqu'on le voir de toute façon dans le formulaire principal ***
    c. Simplement pour montrer que c'est possible, mais il FAUDRA le réafficher par la suite, sinon, on ne saura plus ou on en est
    d. Parce que j'aime bien la choucroute

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.

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 :

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...):

Solution de Critique.mdb  |  Solution de Vivelamour.mdb

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