2009-04-22 5 views
3

Ich habe Josh Smith's CommandSink example von Grund auf neu aufgebaut und meine Version läuft ohne Fehler außer, dass meine Befehlsschaltflächen ausgegraut sind. Ich nehme an, das liegt daran, dass irgendwo etwas nicht richtig eingestellt ist, so dass die Befehle niemals auf CanExecute = true gesetzt werden oder irgendwann auf CanExecute = false gesetzt werden.Wie geht man beim Debugging von Datenbindungsproblemen in MVVM vor?

Da jedoch die Datenbindung im XAML im Wesentlichen stattfindet, bin ich nicht sicher, wo ich einen Haltepunkt für den Befehl setzen soll, damit ich sehen kann, wann eine Schaltfläche zugewiesen ist. CanExecute = false oder z. ist NICHT zugewiesen CanExecute = true.

Im Grunde habe ich diese Befehlsbindungen in einer Ansicht:

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

und in meinem CustomerViewModel der Befehl wie folgt definiert ist:

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"); 
} 

Aber da mein Verständnis von MVVM Recht ist jetzt, dass Sie Richten Sie Ihre M-VM-M ein, führen Sie Ihre Anwendung aus und die Dinge werden "datengebunden und funktionieren einfach".

Ich glaube, ich bin auf der Suche nach so etwas wie ein „Seite-Zyklus“, wie er in ASP.NET, in dem bis zum Schritt, um herauszufinden, wenn meine Befehle CanExecute = true sind und wenn sie CanExecute = false.

Wie könnte man ein WPF/MVVM-Muster wie dieses debuggen, wo die Datenbindung nicht explizit im Code durchgeführt wird, und daher Debugging im klassischen Sinn nicht durchlaufen werden kann?

Antwort:

Obwohl this article that Gishu mentioned hilfreich war allgemein darüber, wie über das Debuggen Datenbindung Fragen zu gehen, und beantwortet im Allgemeinen meine Frage, wie genau das zu tun, es hat mich nicht in meinem speziellen Fall helfen.

Für was es wert ist, dachte ich, mein besonderes Problem mit diesem Code aus, indem Sie eine Zeile pro Zeile Vergleich mit Josh Smith Original-Code zu tun und fand diese beiden Linien, die von der CommandSinkBinding.OnCommandSinkChanged Methode fehlten:

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

Ist das ein Duplikat (zumindest in Bezug auf die Antwort)? von [http://stackoverflow.com/questions/337023/how-to-detect-broken-wpf-data-binding](http://stackoverflow.com/questions/337023/how-to-detect-broken- wpf-data-binding) Sie könnten auch google für Bea Stollnitz Artikel auf dem gleichen. – Gishu

+0

Der Link im Antwortteil ist jetzt tot :( –

Antwort

0

Erster Punkt:

XAML debuggen Bindung Sie Bezug auf Diagnose von Windows dll in die XAML-Datei hinzufügen können, dann, wenn sie eine Eigenschaft Bindung hinzufügen PresentationTraceSources.TraceLevel. Wenn Sie es ausführen, überprüfen Sie das Ausgabefenster.

XAML Beispiel:

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

Zweiter Punkt:

Ihr Befehl abgeblendet werden bedeutet, dass Ihre Werke verbindlich! Was nicht passiert, ist, dass der Befehl seinen Status nicht aktualisiert, was bedeutet, dass die CanExe() -Methode ausgeführt wird und den Befehl auf "can not exe state" setzt, aber es überprüft nie wieder, ob es seinen Status zurück zu " kann exe ". Es gibt viele Möglichkeiten, dies zu tun, aber grundsätzlich, wenn sich eine bestimmte Eigenschaft in Ihrem ViewModel ändert, aktualisieren Sie Ihren Befehlsstatus:

in Prism, zum Beispiel können Sie someCommand aufrufen.RaiseCanExecuteChanged();

+0

In diesem Beispiel fehlt eine Anleitung darüber, was nach dem Hinzufügen der Diagnoseeigenschaften zu tun ist –