Discussion :

[Pol63]

bonjour

une petite question pour savoir s'il y des méthodes connues ou efficaces, car c'est une chose que je trouve pas toujours évidente à coder proprement ; le cas d'une saisie dont un élément est visible/enabled/obligatoire selon la valeur d'un autre élément

je me retrouve des fois avec une fenêtre qui demande une dizaine de choses, et selon le choix dans une liste je dois verrouiller un controle, rendre visible un autre tout en modifiant la collection Items d'un combobox etc... et selon le choix suivant c'est une autre valse qui contredit parfois l'ancienne ^^ etc...
ajouté à cela, nous sommes plusieurs à prendre le relais sur chaque appli, mettant un peu plus de bordel à chaque modif demandée par le client

j'ai donc au final un code pas très maintenable avec des .enabled partout, la gestion des CheckChanged ou SelectedChanged ...
sans parler du code du bouton valider qui se retrouve avec une requête qui parfois diffère légèrement selon le cas et les tas de tests d'obligatoire ou non pour forcer la saisie

y a t il donc des bonnes pratiques sur ce sujet ? vos techniques ?
merci

[mactwist69]

J'ai un peu le même cas en ce moment:

Plusieurs, Combobox, listview etc... Avec quand même une certaine hiérarchie. On gérai tout dans le code (enable, visible, liste d'élément) mais comme toi, la multitude des cas était a se tirer les cheveux.

On passe donc maintenant par une base, propre et hiérarchise:

Param_niveau1, Param_niveau2, Param_niveau3 etc...

Avec pour la première table un auto-incrément, libellé.
Pour les autres: Auto-incrément, clé-étrangère table supérieur, libellé.

Ensuite un seul principe: Au change d'un élément, appelle en base des infos du niveau inférieur, avec la clé étrangère et sélection par défaut du premier, qui déclenche le "change" du niveau inférieur etc etc.

Les requêtes sont ultra rapides, les évènements en cascades infaillible. Les mises à jour sont faciles et dynamique (pas comme du code en dur).

Après je ne sais pas si ça peut s'appliquer a ton cas.