WPF-Bindings sind schwer zu debuggen. Heute habe ich 15 Minuten für den Grund eines nicht funktionierenden Bindings gesucht, um am Ende festzustellen, dass ich vergessen hatte den DataContext zu setzen. Hier ein Tipp, wie man WPF ein paar Debug-Ausgaben entlockt, um solche Problem etwas schneller zu identifizieren.
Das folgende XAML-Dokument beschreibt ein Fenster mit einem Button. Im CodeBehind gibt es eine Property Message
vom Typ String, deren Wert per Binding als Text auf dem Button erscheinen soll.
<Window x:Class="BindingExample.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Grid>
<Button Content="{Binding Message}" Margin="20"/>
</Grid>
</Window>
Da ich den DataContext nicht gesetzt habe, zeigt der Button beim Ausführen des Programms aber keinen Text an.
Aufgrund des fehlenden DataContext wird kein Text auf dem Button angezeigt
In einem solchen Fall fällt mein Blick normalerweise sofort auf die Debug-Ausgabe in Visual Studio um dort nach Hinweisen zu suchen. In diesem Fall gibt es aber leider, wie der folgende Screenshot beweist, keinerlei Ausgabe betreffend des Bindings.
Die Debug-Ausgabe enthält keine Informationen, die bei der Fehlersuche hilfreich wären
Um weitere Debug-Ausgaben zu erhalten, kann das Binding folgendermaßen um die AttachedProperty TraceLevel
aus dem Namespace System.Diagnostics erweitert werden (hier gehts zur MSDN-Doku):
<Button Content="{Binding Message, PresentationTraceSources.TraceLevel=High}" Margin="20"/>
Wird das Programm nun erneut ausgeführt, erscheinen in der Debug-Ausgabe weitere Details zu dem Binding:
Die Debug-Ausgabe enthält nun weitere Informationen zum Binding
Der Ausgabe ist zu entnehmen, dass kein DataContext gesetzt ist und daher null
als Fallback-Wert verwendet wird. Damit ist das Problem identifiziert und kann behoben werden.
Mit DataContext funktioniert das Binding
Ähnliche Artikel
Schon seit Längerem arbeite ich bei der Entwicklung mit diversen PowerShell-Scripten. Dazu hatte ich mir in Visual Studio ein "External Tool" eingerichtet, das die PowerShell im aktuellen Solution-Verzeichnis öffnet. Nun...
Ein weiterer Post aus der Kategorie "Gedankenstütze, die vielleicht auch für jemanden anders nützlich sein könnte. Heute: Den Standard-Dateimanager unter Ubuntu (Nautilus) durch Nemo (Standard-Dateimanager unter Linux Mint) ersetzen. (mehr …)
Um Platz auf meinem virtualisierten Domänen-Controller zu sparen, wollte ich die vom WSUS verwalteten Updates auf ein Netzlaufwerk auslagern. Die Einstellungen waren schnell getätigt, die Clients waren jedoch nicht mehr...