J'ai remarqué que Cela signifie que je dois plutôt écrire ma classe personnalisée myobservablecollection à la place.
Quelle est la raison de ce comportement?
merci Observablecollection dans WPF reflète les modifications de l'interface graphique uniquement en ajoutant ou en supprimant un élément de la liste, mais pas en le modifiant.
5 Réponses :
L'observablecollection n'a aucun moyen de savoir si vous apportez des modifications aux objets qu'il contient - si vous souhaitez être averti lorsque ces objets changent, vous devez également rendre ces objets observables également (par exemple, en ayant les objets mis en œuvre inotifyProperTychanged)
Alors ok. Je implémente une interface d'inotifyporpertyChanged. Merci
Probablement parce que les articles n'ont aucun moyen d'alerter la collection quand ils sont édités - c'est-à-dire qu'ils ne seraient peut-être pas observables. D'autres classes auraient un comportement similaire - aucun moyen de vous avertir à chaque changement de graphique des classes référencées.
En tant que contournement, vous pouvez extraire l'objet de la collection, puis le réinsérer après avoir terminé le traitement. En fonction de vos besoins et de vos modèles de concurrence, cela pourrait tout cependant faire le programme laid. C'est un piratage rapide et ne convient pas à tout ce qui nécessite une qualité.
Au lieu de cela, vous pouvez mettre en œuvre la collection avec une méthode de mise à jour qui déclenche spécifiquement le événement ContentChanged (pas sûr de l'événement Nom). Ce n'est pas jolie, mais c'est au moins facile à gérer.
Idéalement, comme le dit Kragen2uk, il serait préférable de rendre les objets observables et de conserver votre code client propre et simple.
Voir aussi Cette question .
L'extraction et la réinsération est un piratage vraiment sympa :) Maintenant, je sais que je dois oublier ce truc :)
Un autre moyen d'atteindre ce serait que vous impliquerez une nouvelle classe XXXViewModel qui dérive de dépendanceObject et vous mettez celui-ci à l'observaCollection.
Pour ce regard sur cette très bonne introduction MVVM: http://blog.lab49.com/archives/2650 p>
Un exemple pour une telle classe serait Soyez: P>
public class EntryViewModel : DependencyObject
{
private Entry _entry;
public EntryViewModel(Entry e)
{
_entry = e;
SetProperties(e);
}
private void SetProperties(Entry value)
{
this.Id = value.Id;
this.Title = value.Title;
this.CreationTimestamp = value.CreationTimestamp;
this.LastUpdateTimestamp = value.LastUpdateTimestamp;
this.Flag = value.Flag;
this.Body = value.Body;
}
public Entry Entry
{
get {
SyncBackProperties();
return this._entry;
}
}
public Int64 Id
{
get { return (Int64)GetValue(IdProperty); }
set { SetValue(IdProperty, value); }
}
// Using a DependencyProperty as the backing store for Id. This enables animation, styling, binding, etc...
public static readonly DependencyProperty IdProperty =
DependencyProperty.Register("Id", typeof(Int64), typeof(EntryViewModel), new UIPropertyMetadata(new Int64()));
}}
Semble intéressant, mais je ne comprends pas dans quel but hériter de dépendanceObject? Les propriétés de dépendance liées à WPF à l'intérieur de la classe doivent être suffisantes. ou?
@ PAN1C_SHOWT1ME: GetValue / SetValue y est mis en œuvre. BR Sargola
Ah Ok .. L'UserControl est une dépendanceOv.v .. N'a pas remarqué cela. Merci
Vous pouvez enregistrer une méthode dans la classe de modèle d'affichage Aginst l'événement de la bienfacée des objets de classe de données et les écouter dans la vue du modèle lorsque toute modification de la propriété des objets de données se produit. Ceci est très facile et droit d'avoir le modèle de contrôle du modèle lorsque les éléments d'une collecte observable changent. J'espère que cela vous aidera ...