2009-04-22 4 views
3

J'ai reconstruit Josh Smith's CommandSink example à partir de zéro et ma version fonctionne sans erreur sauf que mes boutons de commande sont grisés. Je suppose que c'est parce qu'il y a quelque part quelque chose qui n'est pas réglé correctement pour que les commandes ne soient jamais réglées sur CanExecute = true ou à un certain point sur CanExecute = false. Mais comme la liaison de données est essentiellement en cours dans le XAML, je ne suis pas sûr où "définir un point d'arrêt sur la commande" afin que je puisse voir à quel moment un bouton est affecté CanExecute = false ou par exemple. n'est pas affecté CanExecute = true.Comment faire pour résoudre les problèmes de liaison de données dans MVVM?

Essentiellement, j'ai ces liaisons de commande en vue:

<UserControl.CommandBindings> 
    <sink:CommandSinkBinding Command="vm:CustomerViewModel.CloseCommand"/> 
    <sink:CommandSinkBinding Command="vm:CustomerViewModel.ShowInformationCommand"/> 
</UserControl.CommandBindings> 

et dans ma CustomerViewModel la commande est définie comme ceci:

public static readonly RoutedCommand CloseCommand = new RoutedCommand(); 

public bool CanBeClosed 
{ 
    get { return _customer.IsOpen; } 
} 

public void Close() 
{ 
    _customer.IsOpen = false; 

    this.OnPropertyChanged("CanBeClosed"); 
    this.OnPropertyChanged("CanBeApproved"); 
} 

Mais depuis ma compréhension de MVVM droit est maintenant que vous configurer votre M-VM-M, exécutez votre application et les choses "obtenir des données liées et juste travailler".

Je suppose que je cherche quelque chose comme une « page Cycle », comme dans ASP.NET dans lequel à l'étape par pour savoir quand mes commandes sont CanExecute = true et quand ils sont CanExecute = false. Comment peut-on procéder au déboguage d'un modèle WPF/MVVM comme celui-ci où la liaison de données n'est pas faite explicitement dans le code, et donc on ne peut pas passer par le débogage au sens classique?

Réponse:

Bien que this article that Gishu mentioned a été utile en général sur la façon d'aller sur le débogage des problèmes de liaison de données, et a répondu à ma question générale sur la façon de le faire, il ne m'a pas aidé dans mon cas particulier.

Pour ce que ça vaut, je me suis mon problème particulier avec ce code par faire une comparaison ligne par ligne avec le code original de Josh Smith et ont trouvé ces deux lignes qui ont été absents de la méthode CommandSinkBinding.OnCommandSinkChanged:

if (!ConfigureDelayedProcessing(depObj, commandSink)) 
    ProcessCommandSinkChanged(depObj, commandSink); 
+0

Est-ce un doublon (au moins en termes de réponse)? de [http://stackoverflow.com/questions/337023/how-to-detect-broken-wpf-data-binding](http://stackoverflow.com/questions/337023/how-to-detect-broken- wpf-data-binding) Vous pouvez également google pour l'article de Bea Stollnitz sur le même. – Gishu

+0

Le lien dans la partie réponse est maintenant mort :( –

Répondre

0

premier point:

pour déboguer XAML Binding vous pouvez ajouter une référence à des diagnostics de dll WindowsBase au fichier XAML, puis lors de la liaison à une propriété ajouter PresentationTraceSources.TraceLevel. Lorsque vous l'exécutez, consultez la fenêtre de sortie.

échantillon XAML:

<TextBlock Text="{Binding someProperty, diagnostics:PresentationTraceSources.TraceLevel=High}"/> 

Deuxième point:

votre commande étant grisés signifie que votre association fonctionne! Ce qui n'arrive pas, c'est que la commande ne rafraîchit pas son état, ce qui signifie que la méthode CanExe() s'exécute et met la commande à "ne peut pas exe state", cependant elle ne vérifie plus jamais si elle peut revenir à " peut exe ". Il y a plusieurs façons de le faire, mais quand une certaine propriété change dans votre ViewModel, rafraîchissez votre état de commande:

dans Prism, par exemple vous pouvez appeler someCommand.RaiseCanExecuteChanged();

+0

Cet exemple ne contient pas de conseils sur ce qu'il faut faire après avoir ajouté les propriétés de diagnostic –

Questions connexes