DataContext Refresh et PropertyChanging & amp; PropertyChanged Events

Question

Je me trouve dans une situation où je suis informé par une source externe qu'une entité particulière a été modifiée en dehors de mon contexte de données actuel. Je suis en mesure de trouver l'entité et d'appeler l'actualisation comme si

MyDataContext.Refresh (RefreshMode.OverwriteCurrentValues, myEntity);

et les propriétés qui ont été modifiées sur l'entité sont mis à jour correctement. Toutefois, ni INotifyPropertyChanging, INotifyPropertyChanged ne semble être levé lorsque la régénération a lieu, ce qui laisse mon interface utilisateur afficher des informations incorrectes.

Je suis conscient que Refresh () n'utilise pas les getters et les régleurs de propriété corrects sur l'entité pour déclencher les événements de notification de modification, mais il existe peut-être un autre moyen d'accomplir la même chose?

Est-ce que je fais quelque chose de mal? Existe-t-il une meilleure méthode que Refresh? Si l'option Actualiser est la seule option, est-ce que quelqu'un a une solution?

Answer 1

J'ai eu un problème similaire. J'étais lié à un TreeView et j'avais besoin d'appeler Refresh en réponse à l'annulation par l'utilisateur d'une opération d'édition. La méthode Refresh () remet docilement toutes les valeurs d'origine, mais cela n'a pas été reflété dans mon TreeView UI. Après avoir consulté le tout-puissant Google, je suis tombé sur cette solution:

CollectionViewSource.GetDefaultView(treeViewClusters.ItemsSource).Refresh();

Cela semble forcer mon TreeView à tout mettre à jour. Le seul inconvénient (et il s'agit d'un problème assez important) est qu'il semble effacer tous les nœuds d'arborescence, ce qui entraîne la perte de la place de l'utilisateur. Je pourrais aussi bien définir mon ItemsSource sur null et revenir encore ... même effet, même si cette méthode serait plus simple si vous aviez un tas de zones de texte liées ou quelque chose, car vous n'auriez pas besoin relier chacun d'entre eux.

Existe-t-il une meilleure solution que celle-là?

MODIFIÉ: Oui, il y a ...

Un de mes collègues plus intelligent que moi a mis au point cette solution, qui semble faire l'affaire. Dans votre classe partielle pour l'objet Linq2Sql, ajoutez le code suivant:

public void SendPropertiesChanged()
{
     foreach (System.Reflection.PropertyInfo prop in this.GetType().GetProperties())
     SendPropertyChanged(prop.Name);
}

Vous pouvez simplement appeler cela dans votre code d'application:

context.Refresh(RefreshMode.OverwriteCurrentValues, employee);
employee.SendPropertiesChanged();

Tous les éléments de l'interface utilisateur reçoivent le message et se mettent à jour de manière appropriée. Cela fonctionne même pour les contrôles d’arborescence et les choses de ce type où vous ne voulez pas que l’interface utilisateur apparaisse comme "réinitialisée". lorsque vous actualisez les liaisons.

Answer 2

Si vous savez appeler Refresh (), pourquoi ne pas simplement actualiser l'interface utilisateur à ce moment-là?

PropertyChanging et PropertyChanged sont invoqués en appelant l'afficheur dans une classe d'entité LINQtoSQL générée par DBML. L'appel de Refresh () ne fait pas cela:

[Column(Storage="_DisplayName", DbType="VarChar(50) NOT NULL", CanBeNull=false)]
public string DisplayName
{
    get
    {
        return this._DisplayName;
    }
    set
    {
        if ((this._DisplayName != value))
        {
            this.OnDisplayNameChanging(value);
            this.SendPropertyChanging();
            this._DisplayName = value;
            this.SendPropertyChanged("DisplayName");
            this.OnDisplayNameChanged();
        }
    }
}