Discussion :

[myCollections]

Bonjour,

J'utilise une Datagrid (WPF4) que je bind avec une List<T>. Dans ce cas tout fonctionne bien.

En revanche si je bind avec une Collection<T> tel que recommandé par "Code Analysis" dans ce cas lorsque j'appuie sur la touche "Delete" pour effacer la ligne sélectionné cela ne fonctionne plus.

Ce comportement est-il normal ? si oui pourquoi ?

Merci pour votre aide.

[obito]

Bonjour, il ne faut pas plutôt binder sur une ObservableCollection ?

Par ailleurs il existe aussi les BindingList, si tu t'interesse au binding.

[cinemania]

On peut binder sur toute forme de Collection obito... tout dépend des besoins en réalité.

Déjà c'est assez surprenant que cela fonctionne sur une List<> en règle générale, mais sur une Collection c'est normal. En effet, Collection est un modèle générique, mais il est préférable d'opter pour une implantation particulière de Collection qui plus est fortement typée.

L'intérêt de faire un binding sur une ObservableCollection<T> (System.Collections.ObjectModel) c'est que c'est une collection qui implémente l'interface INotifyPropertyChanged, et sur laquelle on peut réclamer une vue par défaut.

En fait dès lors que l'on demande la vue par défaut sur une instance de ObservableCollection, on obtient la même vue que celle utilisée par WPF, en effet, WPF ne bind pas directement l'ObservableCollection, mais une vue sur celle-ci, ICollectionView.
L'intérêt est que sur l'ObservableCollection on va pouvoir récupérer tout changement d'état de celle-ci à la fois du coté de la logique, et également du coté de wpf, si des ajouts ou retrait sont fait coté logique.
Mais sur la vue on va pouvoir également déterminé l'élément sélectionné (si on est en mode 1 seul... en effet, s'il y en a plusieurs seul le premier est indiqué, il faut donc procéder autrement) et également appliquer des filtres pour ne sélectionner que les éléments à afficher correspondant aux critères voulus.
Là par contre le filtrage n'a plus rien avoir avec les DataView fortement utilisés sous Winforms, puisqu'on va devoir définir un prédicat qui pour chaque élément de la vue retournera la condition de vue ou non, ceci permet d'écrire des filtrages extrêmement puissants sans toucher à la collection.

Ce fonctionnement est idéale pour recourir au pattern MVVM.
Je te conseillerais donc d'oublier Collection et de passer à ObservableCollection<T> pour ta collection à binder à ton DataGrid.

Généralement on utilise un binding sur une List ou une Collection ou un T[] seulement quand on souhaite avoir un affichage sans modification particulière, ni interaction utilisateurs quelconque sur les contrôles d'affichages.
Dès lors que les besoins sont plus évolués en terme d'interactivité, donc typiquement une DataGrid, il est préférable d'avoir recours à des systèmes plus évolués comme des vraies BindingList donc ObservableCollection<T> par exemple.

[obito]

Merci pour les précisions, du coup, je pense à implenter un ObservableCollection et une ICollectionView plutôt que mon DataView (pour mon problème sur la copie du DataView), j'avais l'habitude de faire ça en WinForm mais la on est en dans un mode de fonctionnement complètement différent, il va falloir que je m'y fasse.

Après je savais qu'on pouvait binder sur toute formes de collection, mais le principal interêt est de pouvoir manipuler les données affichées et avec de simple List/Collection ca ne me paraissait pas trop possible.

[cinemania]

obito effectivement ce n'est pas possible car ces 2 collections n'ont pas de mécanismes de backtracking et ne peuvent pas te renseigner sur un changement éventuel d'état.

en même temps ce n'est clairement pas leur but, et donc leur utilisation première

effectivement utiliser des DataView en WPF ca fait un peu bizarre surtout lorsqu'on connait les possibilités en terme de binding de WPF comparées à celles des winforms qui étaient déjà pas mal en leur temps
Disons que là, on est carrément dans une autre sphère, pour peu que tout ce qui est nécessaire implante les bons interfaces.

Il est important que les données manipulées par tes collections implémentent elles même INotifyPropertyChanged, si tu veux profiter au maximum du binding.
C'est le cas des entités générées par Entity Framework qui implantes toutes le INotifyPropertyChanged ou un équivalent (par le biais des héritages)

Lorsque les collections, et les entités implantent toutes ces interfaces, on peut faire un binding dans les 2 sens (TwoWay) sinon on est contraint d'envisager un binding plus passif, sans spécifier le type de liaison, ou seulement dans un sens donc OneWay ou OneWayToSource.

[Pragmateek]

L'intérêt de faire un binding sur une ObservableCollection<T> (System.Collections.ObjectModel) c'est que c'est une collection qui implémente l'interface INotifyPropertyChanged, et sur laquelle on peut réclamer une vue par défaut.

Petite précision : c'est l'interface INotifyCollectionChanged qui spécifie la notification en cas de modification du contenu de la collection, comportement le plus souvent utilisé.