Discussion :

[LedZeppII]

Bonjour,

Je suis content que tu ai trouvé une solution.
Je ne vois pas comment on aurait pu résoudre le problème de lenteur de rafraîchissement.

Le fait de créer une table dédiée au formulaire, pourrait même permettre de s'affranchir de la table contenant les sélections.
En effet, en créant la table, tu pourrai ajouter le champ de sélection.
Il remplacerait le champ calculé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IIf([tblSelectionFmSelecteur]![Réf produit] Is Not Null,"S","N") AS [Select]

et on n'aurait plus besoin de faire le Me.Requery (rafraîchissement) pénalisant.
C'est à dire qu'on peut se passer de la fastidieuse Sub ActualiserFormulaire().

Il faut que je teste , pour vérifier que dans la pratique ça fonctionne.
Mais j'ai le sentiment que ça doit simplifier pas mal de choses.

A+

[Access_ible]

Bonsoir.
Merci de cette info et pour tout le reste.

Je ne vais pas pouvoir tester cette proposition avant Lundi.

Mais si je comprends bien, le formulaire principal, celui contenant le sélecteur et le code, serrait basé sur une table qui contiendrait en gros le champ "sélectionné, oui/non" et qui permettrait de donner cet effet de surbrillance.

Mais cela voudrait dire qu'il faudrait quand même je pense rafraîchir l'affichage du formulaire sélecteur à chaque nouvelle ligne sélectionnée, puisque le contenu de la table sélecteur (oui, c'est bien de la table sélecteur) serrait modifié à chaque nouvelle ligne.

Ou alors quelque chose m'a échappé…

Par ailleurs, je suis très satisfait que la sélection se fasse dans une table à part.

On peut ensuite, comme je l'ai fait, installer un genre de barre d'outils pour permettre à l'utilisateur de choisir ce qu'il fait de sa sélection (Etat, nouveau formulaire, export…) le tout uniquement avec des mises à jour de tables comme je l'ai fait moi…

J'ai réussi, sans aucune modif du code, à utiliser deux sous-formulaires sélecteurs utilisant le même champ clé et la même table de sélection, mais avec des infos différentes d'un formulaire à l'autre.

J'ai réussi à effectuer des sélections dans les deux formulaires.

Dans mon cas il ne peut y avoir de dédoublement d'informations.

Quand un champ clé pends une valeur dans un des deux formulaires, il ne peut avoir la même valeur dans le second.
Faute de quoi, sélectionner une ligne dans le premier formulaire et en sélectionner une de même valeur dans le second, reviendrait à la désélectionner du premier (selon le principe explicitement demandé je l'avoue, de resélectionner = déselectionner)

Le système de formulaire basé sur une table "en dur" comme source du formulaire, puis une requête pour la liaison avec la table sélection pour la surbrillance est bien.

Attention cependant, j'ai pu constater que cette dernière requête ne peut recourir à la fonction regroupement.
Si pour quelque raison que ce soit les tables utilisées dans cette dernière requête comportait des doublons sur les champs liés, il devrait normalement être possible de les "gommer" avec la fonction regroupement.

Malheureusement, si à l'affichage le formulaire sélecteur ne propose qu'une ligne par valeur, quand on sélectionne une des lignes avec doublon "en arrière plan" la sélection "apparaît" comme décalée (du moins le rendu de la surbrillance), comme si le sélecteur percevait le doublon et comptait autant de lignes.

J'ai modifié mes tables et requêtes pour ne pas avoir à recourir à cette fonction de regroupement.

Je ne pense pas qu'il soit utile de passer plus de temps sur le développement de ce système. Les premiers résultats montrent qu'il est efficace, pratique et performant. Les seules choses qui le mettent en péril sont les bricolages que j'élabore autour.

Encore merci

[Access_ible]

Bonjour.

Etant donné que plus personne ne poste de réponses, j'opte pour Résolu.

Un immense merci notamment à LedZepII, le magicien d'Access

Merci.