Transfert sélection de liste déroulante dans sous formulaire

[Sacer26]

Bonjour,

Mon formulaire "Formation des salariés" (je précise car il y a en a un autre) affiche les noms des salariés de ma boite, et dans le sous formulaire, lié par un champ identifiant, les formations effectués par le salarié en cours. Ce sous formulaire sert aussi à saisir/modifier les formations.

Pour faciliter la saisie des formations - et pour éviter que chacun écrive le nom de la formation à sa façon - j'ai une liste des formations disponibles. Je voudrai que quand une formation est sélectionnée dans la liste (click par ex) je puisse transférer l'info dans le champ approprié du sous formulaire, sur double-click, bouton valider ou autre.

Bien entendu, la difficulté vient du sous formulaire : si le transfert devrait se faire vers le formulaire principal, je n'aurai eu qu'à indiquer le champ destination dans l'assistant. Mais là, y a pas !

Est-ce possible sans code ?

Merci

[Sacer26]

Personne ne peut m'aider ?

[Pierre-Yves Samyn]

Bonjour

Personne ne peut m'aider ?

Ici comme ailleurs pouvoir n'est pas tout

Cela dit, oui c'est possible facilement et sans macro : il "suffit" de remplacer la colonne Formation par une liste déroulante affichant la liste des formations.

Pour cela, clic droit sur l'en-tête de la colonne (en modification de formulaire bien entendu) puis choisir Remplacer > Liste déroulante (le menu de la copie d'écran ne propose plus ce choix car j'ai déjà effectué la transformation. OOo n'affiche que les choix disponibles).

Capture-1.png

Avec cette manière de procéder ta liste figurant au dessus du sous-formulaire est désormais inutile.

Pour le reste, il faut indiquer le champ lié (FormationsSalariés > Formation) et la source de la liste :

Code : Tout sélectionner

SELECT "TypeFormation", "TypeFormation" FROM "TypesFormations"

Pourquoi deux fois TypeFormation ? Parce qu'en principe, avec une base relationnelle, on affiche un libellé et on stocke un identifiant. Tu as choisi (mauvais choix selon moi) de stocker le libellé ce qui introduit une redondance (identifiant plus court qu'un libellé) et surtout ne facilite pas les mises à jour (si tu modifies le libellé dans la table des formations).

Donc une liste "attendant" deux champs on lui indique deux fois le libellé et on indique quel est le champ lié (1 sachant que la numérotation commence à zéro).

Je te déconseille également ton choix d'identifiant pour la table FormationsSalariés (reprise de l'identifiant salarié + nom de la formation, si j'ai bien compris).
Ce choix ne permettra pas de suivre plusieurs fois une formation de même nom... Il vaudrait mieux créer un champ "spécifique" (éventuellement en auto-valeur) qui sera la clé de cette table. En revanche, il faut bien sûr garder les champs "id salarié" et "formation" (même si, encore une fois, je te conseille plutôt de stocker là un identifiant formation) et le mieux est de créer un index pour chacun de ces champs (pour des raisons de performance car ils seront sollicités dans les relations, dans les formulaires, requêtes...).

[Sacer26]

Merci pour l'astuce de la liste modifiable, c'est tout à fait ce que je cherche.

Pour le choix des identifiants dans la table TypeFormation, je suis parti du principe que le libellé est unique (il n'y a pas besoin de plusieurs formations du même nom), donc qu'il ferai un très bon identifiant. Je ne vois pas bien en quoi c'est gênant.
Pour le choix de la clé primaire salarié+formation, c'est pareil : ce couple est unique car un salarié ne fait qu'une fois la même formation. Si des modifications doivent être enregistrées (recyclage, fin de validité par exemple) on modifie simplement l'enregistrement initial. Là encore c'est peut-être une erreur de ma part. Mais je suis attentif à toute critique !!