Discussion :

[coqp]

Bonjour,

J'ai une liste de matériel saisis dans la base. Une fois les saisies effectuées, je ne souhaite pas que l'utilisateur puisse modifier librement les données. Mais il doit pouvoir effectuer des corrections si besoin. Pour limiter le risque de fausse manip, j'ai donc prévu :
- un sous-formulaire dans lequel on filtre les enregistrements à modifier
- au clic sur "Lire", des contrôles de formulaire remplis avec les valeurs extraites du sous-formulaire
- au clic sur "Actualiser", requête de mise à jour en vba avec les valeurs des contrôles

Ca se complique quand j'ajoute la fonction suivante :
On doit pouvoir choisir plusieurs enregistrements avec le sous-formulaire. Pour un champ donné, si les valeurs sont différentes d'un enregistrement à l'autre, j'affiche un texte par défaut (ex: "Valeurs multiples") et je verrouille le contrôle. Le contrôle n'est autorisé pour modif que lorsque la valeur est commune à tous les enregistrements. (ex: 50 matériels différents pour lesquels un champ 'Commentaire' vide à l'origine doit être rempli avec une même valeur).

Problème 1 :
J'ai normalement des champs contenant des clés étrangères (ex: type_ID), que j'affiche dans une liste déroulante en clair (ex: type_nom) en stockant la valeur numérique. Mais je ne peux pas faire ça tout en affichant ma chaîne "Valeurs multiples" car incompatibilité de type. Si je veux afficher mon texte en clair, je ne dois plus stocker la clé étrangère, mais le texte en clair, ce qui complique beaucoup de choses.
Si au lieu d'afficher une chaîne "Valeurs multiples", j'affecte la valeur Null, ça résout ce problème mais ça me complique le problème n°2 ci-dessous.

Problème 2 :
Existe-t-il un moyen de choisir l'ordre des Controls du formulaire pour pouvoir les parcourir par un index plutôt que par leur nom ? Ou peut-être leur affecter une constante numérique qu'on pourra réutiliser dans la suite du code ?
Ma méthode actuelle pour verrouiller les contrôles concernés consiste à parcourir tous les contrôles, à trier sur les types (TextBox, etc.) ainsi que détecter la valeur spéciale "Valeurs multiples". Si au lieu de cette valeur, j'affecte Null, je ne peux plus distinguer le cas où tous les enregistrements ont ce champ vide et le cas où les enregistrements ont des valeurs différentes pour ce champ.

Problème 3 en bonus:
Pour des raisons de facilité de lecture pour l'utilisateur, la requête sur laquelle est basée le sous-formulaire renvoie des champs construits "Expr1", "Expr2", etc. Cela me pose problème lorsque je veux attribuer la valeur réelle au clic sur le bouton "Actualiser" car le champ "Expr1" du sous-formulaire n'est pas actualisable puisqu'il ne correspond à aucune table. Des idées sur la meilleure manière de gérer cela ? Je voudrais généraliser au maximum le code pour éviter d'avoir trop de tambouille spécifique à telle ou telle Expression.

Je suis bien sûr preneur d'une toute autre solution.

[Zekraoui_Jakani]

Pouvez-vous, si possible, poster copie compressée de votre DB (sans info confidentielles, quitte à y mettre des données-bidons) ?

[coqp]

Voici la version de test.
Le code est incohérent puisque j'ai commencé à tester les différentes pistes évoquées à différents endroits.

[Zekraoui_Jakani]

Si j'ai bien compris la logique, il s'agit de permettre à l'utilisateur de changer un ou plusieurs enregistrements, puis mettre à jour les champs correspondants.
Si tel est le cas, je pense pouvoir concevoir une solution plus pratique :
L'idée est de récupérer les données sélectionnées dans une table temporaire
Les afficher dans un formulaire dédié pour permettre à l'utiisateur de les modifier à souhait, puis lancer la mise à jour.
Cela dit, pourquoi ne pas permettre à l'utiisateur de changer les données directement dans le formulaire principal ?

[Paraffine]

Si on ne peut pas gérer l'affichage des valeurs multiples dans le contrôle concerné... pourquoi ne pas le faire à côté ? Le verrouillage du contrôle s'accompagne par exemple de l'affichage d'une étiquette qui est masquée ou "vide" le reste du temps. En utilisant par exemple un nom d'étiquette qui inclut le nom du contrôle pour pouvoir généraliser le comportement.
Et plutôt que tester la présence d'une information "Valeurs Multiples", pourquoi ne pas interroger simplement la propriété "verrouillé" du contrôle ?
Concernant les colonnes de la requête sous-jacente du sous-formulaire, je ne vois pas en quoi Expr1 est plus "lisible" qu'un nom de colonne. Et puis l'ergonomie est à traiter côté formulaire, pas requête ; il doit me manquer un élément pour comprendre le problème... Cela dit, si problème de "traduction" il y a, il faut une table de traduction ; ou une liste déroulante masquée, par exemple.

[coqp]

Merci pour vos réponses.

... puis mettre à jour les champs correspondants.

Oui, seulement pour les champs pour lesquels tous les enregistrements choisis ont la même valeur

pourquoi ne pas permettre à l'utiisateur de changer les données directement dans le formulaire principal ?

L'interface sera utilisée entre autres par des novices en Access. Je veux limiter le plus possible les fausses manipulations car sur un formulaire basique, il me semble vite arrivé de supprimer des données par mégarde.
L'idée est que les cas de figure où l'utilisateur aura besoin de modifer des données précédemment enregistrées seront rares. Généralement, il s'agit d'une entrée erroné dans un champs, commune à plusieurs enregistrements. D'où l'idée de ne permettre de modifier les champs d'enregistrements multiples que dans le cas où leurs valeurs sont communes.

pourquoi ne pas le faire à côté ?

Oui j'ai envisagé de faire ça. Ça me paraissait un peu lourd et un peu bricolé. J'utilise régulièrement des champs masqués pour me dépatouiller de différents problème. Mais je me dis que c'est plus compliqué à comprendre si qqn doit un jour faire des modifications à ma place. Mais effectivement, je vais peut-être me rabattre là-dessus.

pourquoi ne pas interroger simplement la propriété "verrouillé" du contrôle ?

A cause de la structure de mon code, qui n'est probablement pas optimale :
1) Je remplis un Array avec les valeurs à écrire dans les contrôles du formulaire
2) Je nomme chaque controle par son nom et lui affecte la valeur de l'array. Ca ressemble à ça :

Code :

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

1
2
3
Me.Nom_du_controle1.Value = Array(3)    ' l'affectation de l'index d'array est fait à la main, en fonction de l'ordre constaté issu du sous-formulaire
Me.Nom_du_controle2.Value = Array(7)
Me.Nom_du_controle3.Value = Array(12)

3) Je parcours tous mes contrôles et selon leurs valeurs (ou du coup selon l'étiquette associée), je modifie les propriétés "Verrouillé" et d'affichage (italique, etc.)
C'est pour parcourir les contrôles que j'aurais aimé pouvoir faire référence à un index de contrôle, obtenu à l'étape où j'affectais la valeur. Mais ça ne semble pas possible.

Je ne vois pas en quoi Expr1 est plus "lisible" qu'un nom de colonne

On s'est mal compris. Je n'affiche pas littéralement 'Expr1' à l'utilisateur. Mais je construis une chaîne spécifique pour l'affichage, basé sur la valeur de ce champ, qui est plus longue. Supposons un champ [Type_vehicule] qui contient soit "Véhicule léger" soit "Poids lourd", ça consisterait à n'afficher que "VL" ou "PL". Ca me permet de synthétiser l'affichage, de gagner de la place.
Le problème avec ça, c'est que pour la mise à jour, je construis un Recordsetclone basé sur le sous-formulaire, lui-même basé sur la requête qui inclut le champ Expr1, plutôt que "[Type_vehicule]". Au moment d'actualiser, j'ai une erreur, puisque Expr1 ne correspond au champ d'aucune table. Je suppose que la solution consiste à intégrer dans la requête à la fois le champ 'Expr1' et le champ [Type_vehicule], utiliser Expr1 pour l'affichage dans le sous-formulaire et [Type_vehicule] pour l'actualisation, mais j'espérais quelques chose de plus robuste en cas de modification ultérieure de la requête.

Cela dit, si problème de "traduction" il y a, il faut une table de traduction

Ca consisterait en une table temporaire, c'est ça ?

[Paraffine]

A cause de la structure de mon code, qui n'est probablement pas optimale :
1) Je remplis un Array avec les valeurs à écrire dans les contrôles du formulaire
2) Je nomme chaque controle par son nom et lui affecte la valeur de l'array.

Là, pour le coup, si quelqu'un doit reprendre la maintenance, ce ne sera pas simple non plus.

(...) je construis une chaîne spécifique pour l'affichage, basé sur la valeur de ce champ, qui est plus longue. Supposons un champ [Type_vehicule] qui contient soit "Véhicule léger" soit "Poids lourd", ça consisterait à n'afficher que "VL" ou "PL". Ca me permet de synthétiser l'affichage, de gagner de la place.

C'est encore plus compliqué que je ne pensais
En parlant de "traduction", je pensais à une table paramètre pour gérer la correspondance nom d'expression/ nom de colonne.
Mais on dirait qu'il faudrait plutôt : Nom de colonne, Champ de formulaire d'un côté - pour faire la correspondance entre les données et l'affichage en remplaçant l'array -, et de l'autre : Nom de colonne, valeur en base, valeur d'affichage pour se passer des "Expr" qui "réécrivent" les données (avec une traduction à l'aller pour l'affichage "ristretto" et au retour pour la mise à jour).

Ou jouer sur les noms d'expressions et de contrôles pour pouvoir faire l'association en se passant d'une table (le contrôle s'appelle comme la colonne + suffixe, par exemple). D'ailleurs pourquoi ne pas utiliser les alias dans la requête?

Mais il faut quand même "retricoter" la valeur pour remettre en base quelque chose qui ne fasse pas tâche. Parce qu'en affichant VL et PL, on aura des saisies VL ou PL. A MOINS de tout gérer sous forme de radio boutons, cases à cocher et listes déroulantes, puisque dans ces cas-là on dissocie l'affichage et la valeur.

[coqp]

Bonjour,
Merci encore pour vos réponses !
J'ai pour l'instant laissé cette idée en standby. Je me suis rabattu sur plus simple : j'ai mis un petit bouton qui permet à l'utilisateur de déverrouiller le formulaire (qui, de base, ne permet pas les modifs); au moins il y a une action consciente qui limite un peu le risque de fausse manip (ajouté à un système de sauvegarde régulier, etc.).