3 ComboBox, 1 source, 3 selctedItem différent

Bonjour, j'ai trois combobox.
Je leurs ai assigné une seul et même source.
Pour les besoins de mon IHM, je voudrais que lorsque je le décide, mon IHM change automatiquement d'item afficher pour les combobox. Elles afficheront chacune un item différents.

Je me sui donc dit qu'il suffisait de faire :

Code:

---

Macombobox.SelectedItem = "Le nom de l'item à afficher"

---

J'ai essayé cela pour 1 combobox et cela marche, tellement bien que mes 3 combobox sont impactés par le changement !!!!
Mais ce n'est pas ce que je veux !!!!! 8O
J'ai un peu de mal à comprendre la logique là !!!!

Faut savoir qu'une des combobox appelle une méthode update qui met à jour la source des 3 combobox en cas de modifications de certain truc.
Ce n'est pas la combobox sur laqu'elle j'ai applique le code ci dessus.

A votre où est ce que je me plante ?

Bon je viens de comprendre :
3 combobox -> tu sélectionnes un item sur l'une des combobox les autres sont impactés.

Pas terrible quand même !!!!

C'est malheureux comme comportement des combobox. J'ai résolu mon problèm en duplicant ma source pour que chaque combobox est la sienne.

Je pense que c'est entre autres à ça que sert le BindingSource. Visual en crée un systématiquement quand on crée une source de données à partir d'un objet métier, par exemple. Il sert d'intermédiaire entre le métier et l'UI. Du coup, je me demande pourquoi tant qu'à faire il ne gère pas le tri et le filtre, problème récurrent avec la DGV notamment :)

Ce que j'aimerais savoir, d'ailleurs, c'est comment est gérée la notion d'objet courant sélectionné. Je sais pas quel est le type de ta source, mais même avec un type aussi simple que List<T>, deux combos bindées sur cette même liste seront "synchronisées"... Je vois pas trop par quel biais une modif de l'une impacte l'autre.

M'enfin, le temps de bien comprendre tout ça, Linq arrive avec ses nouveaux concepts à digérer :aie:

Peut être aurais je du préciser que je suis en .Net version 1.1 du framework :aie:

donc moi les list<T> j'ai aps le droit :aie:

Ca encore c'est pas bien grave, je parlais de List<T> mais ArrayList aurait été pareil en l'occurence. Juste un conteneur qui gère pas le Binding.
T'as peut être as droit au BindingSource, alors... Il me semble que ça a un ancêtre en 1.1, mais ayant eu la chance de m'attaquer direct au 2.0 j'ai jamais trop approfondi :)

Je ne vois pas comment une combobox marcherait sans. 8O

Moi ce que je ne trouve pas logique c'est le comportement.
Les 3 combo ont la même source mais pour ms cela veut donc dire le même comportement.
Je pense que c'est dû à la gestion des événements.
Quand je selectionne un item dans la combo, cela doit en fait sélectionner un item dans la source.
Alors un évenement est déclenché, et toutes les méthodes liés à cet événement sont appelé.
Les méthodes Textes des combobox doivent être abonné aux événements de changement d'item sur la source. Et c'est là qu'est le problème. La combobox ne devient que l'affichage d'un controle. Donc toutes les COmbo avec la même source -> même comportement.

Citation:

---

Envoyé par ced600

Les méthodes Textes des combobox doivent être abonné aux événements de changement d'item sur la source. Et c'est là qu'est le problème. La combobox ne devient que l'affichage d'un controle. Donc toutes les COmbo avec la même source -> même comportement.

---

Oui, mais si ta source est une ArrayList (ou une List<T>), elle ne balance aucun événement. Elle n'a pas non plus de "CurrentItem". Donc je comprends pas bien comment les combos peuvent être au courant des modifs des unes des autres. Il doit y avoir une classe cachée quelque part qui les lie. :?

Ha c'est parce que ma source peut balancer l'événement. C'est une collection, une StringCollection plus exactement.

Je ne pense pas pouvoir utiliser une ArrayList car j'ai besoin de l'événement selectedItem, TextChange, .....

En gros tu penses manipuler un Control alors que tu manipules un DataSource. C'est pourquoi lorsque je dois faire des actions sur une DataGridView, je modifie de DataSet et non directement la DataGridView.
Le Control n'est que l'affichage de ta source.

Contrec : je pensais moi aussi (et c'est bien dans l'esprit de séparation données / affichage) que le Control n'est que l'affichage de la source, mais il y a visiblement un intermédiaire.
Démo :

Code:

---

1 2 3 4 5 6

List<string> laSource = new List<string>(); laSource.Add("a"); laSource.Add("b"); ComboBox cb1 = new ComboBox(); ComboBox cb2 = new ComboBox();   cb1.DataSource = cb2.DataSource = laSource;

---

Avec ça, alors que la source n'implémente aucune interface particulière autre que IList(pas de IBindingList, etc.), les deux combos sont quand même liées. Les combos ne sont évidemment pas prévenues des modifications de la liste ; mais c'est visiblement au niveau de la couche de présentation que la notion de "SelectedItem" est stockée.

ced600 : en tous cas, dans mon cas personnel à moi que j'ai ;), comme les listes métiers qui sont sources de mes combo / grilles / etc. sont potentiellement liées à plusieurs contrôles, je ne gère pas de SelectedItem au niveau de la DataSource. Ca se discute (les BindingSource, qui se placent au milieu, en ont un il me semble), mais à mon sens, c'est un concept qui relève de la couche de présentation.

Je vois ce que vous voulez dire : En résumant, pour être sur de ne pas me tromper, la méthode SelectedItem est une méthode de la source, et les combobox ne font que l'affichage de celle-ci, du genre elles ont une propriété SlectedItem qui est égal à la propriété SelectedItem de la source.

C'est un peu ce que je reproche à MS, je pense que lorsque l'on fait Macombo.SelectedItem, il est plus intuitif de penser que l'on manipule la propriété de la combo et non celle de la source.

Bon enfin c'est pas grave, vu la taille de la source, la reproduire en 3 exemplaires n'est pas si grav que cela, surtout dans mon contexte où mon soft ne sera que très peu utiliser. Il aide à la config d'un outil, donc une ihm lancé à l'install et quelque rare fois pour ajuster la config.

C'est pas le SelectedItem qui fait defaut mais bien le CurrencyManager du bindingSource.

Salut,

en fait, d'apres ce que j'en ai compris, quand tu assignes la meme liste à plusieurs controls, il vont partager la meme liste eventées qu'elle ait été créé par toi, ou par l'assignation de la datasource (IList transformé en IBindingSource (pas sur)).

En experimentant un peu le sujet, j'avais trouvé qu'elle partage un BindingContext dans lequel se situe les listes deja bindées pour reutilisation, donc si les listes sont lourdes à dupliquer, tu peux essayer ca :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public partial class Form1 : Form { public Form1() { InitializeComponent(); this.Load += new EventHandler(Form1_Load); }   void Form1_Load(object sender, EventArgs e) { List<string> liste = new List<string>(new string[] {"Titi", "Toto", "Tutu"}); comboBox1.BindingContext = new BindingContext(); comboBox2.BindingContext = new BindingContext(); comboBox3.BindingContext = new BindingContext();   comboBox1.DataSource = comboBox2.DataSource = comboBox3.DataSource = liste; } }

---

NB : je n'ai pas poussé plus, donc je ne sais pas du tout comment se comporte les binding dans cette situation, tout ce que je sais, c'est qu'avec une liste on arrive à avoir trois controls ayant des comportements differents. (Vivement le debugging dans les sources du Fx pour comprendre comment ca marche ! =) )