Discussion :

[Petit Rasta]

Bonjour,

Je suis en train de galérer sur les ObservableCollection et les binding dans une ListView.
J'ai remarqué que lorsqu'on clear() une ObservableCollection, si un item était sélectionné dans la ListView il va rester sélectionner après le clear().
Ce qui pose problème lorsqu'on effectue d'autres opérations après la suppression de liste.
J'ai essayé de faire un listView.SelectedItems.Clear() mais cela ne résout pas le problème.
Je suis passé en Binding Mode=TwoWay sur ma listView et j'ai ajouté ceci :

Code :

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

1
2
private ObservableCollection<maClasse> objectCollection = new ObservableCollection<maClasse>();
public ObservableCollection<maClasse> ObjectCollection { get { return objectCollection ; } set { objectCollection = value; NotifyPropertyChanged("objectCollection "); }

Je n'ai pas vraiment eu gain de cause sur mon problème ...
Auriez-vous une solution pour palier à ce phénomène ?

Merci par avance.

[Invité]

Bonjour,

Peut-on en savoir plus sur la manière dont tu utilises la ListView et l'ObservableCollection?

[Petit Rasta]

Oui c'est vrai qu'il manque un peu le contexte.
Pour faire simple, j'ai une application WPF qui a pour fenêtre principale une ListView comme conteneur.
J'ai également des boutons pour importer / exporter les données et faire un reset du ListView.
Là où je rencontre des difficultés, c'est quand avant un second import, je supprime les éléments de ma liste (reset).
Le dernier éléments sélectionné reste sélectionné après un

Code :

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

objectCollection.Clear();

ou un

Code :

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

listView.SelectedItems.Clear();

.
Ce qui fait que mes tests pour savoir si un élément est sélectionné avant de procéder à des opérations sur mes items sont biaisés ainsi que la valeur du SelectedItems qui contient 2 éléments alors qu'il y en a qu'un seul sélectionné du côté de l'UI ...
J'ai pensé que c'était une histoire de binding mais je n'en suis pas vraiment sûr.

[Invité]

Probablement, mais dans tous les cas, il faut nous montrer plus de code. Là par exemple il faudrait que je saches si par exemple tu as renseigné un DataContext, comment la classe associée est organisée, etc...

[Petit Rasta]

Non je n'ai pas géré de dataContext.
Je suis arrivé à me dépatouiller autrement, je pense qu'il faut que je me renseigne un peu plus sur le binding en mode TwoWay ...
Connaitrais-tu un bon tuto là dessus ?

[Invité]

Non je n'ai pas géré de dataContext.
Je suis arrivé à me dépatouiller autrement, je pense qu'il faut que je me renseigne un peu plus sur le binding en mode TwoWay ...
Connaitrais-tu un bon tuto là dessus ?

Tu ne gère donc pas de DataContext, cela veut dire que lorsque tu associe ta liste dans le code XAML, tu indiques alors que la source est la fenêtre elle-même?

En fait dans ce cas de figure, le DataBinding "TwoWay" n'a absolument aucune influence sauf si tu modifies le pointeur de liste "ObservableCollection", ce qui n'a aucun intérêt dans ce cas.

le binding "TwoWay" est utile si tu peux aussi bien modifier une valeur directe aussi bien depuis la vue que depuis le modèle. Par exemple si tu as un champ texte databindé à une propriété "Toto", tu verras une modification si tu modifies aussi bien la valeur de l'IHM que la propriété "Toto" (mais dans ce dernier cas, la classe contenant la propriété "Toto" doit implémenter "INotifyPropertyChanged" et bien faire remonter le message via cette interface).

Avec un objet "ObservableCollection", ce n'est pas pareil : grâce au fait qu'il y a une notification "CollectionChanged", il n'est pas nécessaire que la propriété "ObservableCollection" ait un accesseur "Set" puisque seuls les éléments à l'intérieur sont modifiés.

Après, comme tu ne nous avais pas montré le code que je t'avais demandé...