Kolumne: XAML Expertise

XAML-Tipp: WPF – Data Binding Debugging
Keine Kommentare

In der Kolumne „XAML Expertise“ präsentiert Gregor Biswanger Top-How-tos zum Thema XAML. Einsteiger und fortgeschrittene XAML-Experten sollen hier durch geballtes Wissen gesättigt werden. Heute gibt es folgende Expertise: „WPF: Data Binding Debugging“.

Das Debuggen von Data Binding ist seit der Geburtsstunde von XAML ein unangenehmer Aspekt. Bei einer falschen Data-Binding-Deklaration lässt sich ein WPF-Projekt ohne Probleme erzeugen. Erst zur Laufzeit wird im Output-Fenster ein Fehler angezeigt. In Visual Studio 2015 wurde daher das Setzen eines Breakpoints im XAML ermöglicht. Dies wurde in Visual Studio 2017 allerdings aufgrund technischer Schwierigkeiten wieder entfernt. Als neue Lösung zur genaueren Diagnose wird das Live Visual Tree Tooling zur Debugginglaufzeit angeboten. Dennoch muss der Data-Binding-Fehler nach wie vor über das Outputfenster entdeckt werden, damit daraufhin die neuen Tools zum Einsatz kommen können.

Eine effektive Lösung für dieses Problem ist die PresentationTraceSources-Klasse. Sie ermöglicht ein kontrolliertes Aktivieren der XAML-Trace-Informationen. Diese legt man am besten zum Programmstart in der App.xaml.cs-Datei fest (Abb. 1). In Listing 1 ist zu sehen, wie sie aktiviert werden. Zum Schreiben der Tracinginformationen wurde zusätzlich ein Trace Listener geschrieben und hinterlegt.

Wichtig: Am besten hinterlegt man zusätzlich mit #IF DEBUG in einer Compilerdirektive, ob die PresentationTraceSources gerade aktiv sein soll. Ansonsten kann es zu großen Performanceproblemen kommen, wenn die PresentationTraceSources unnötig im Hintergrund mitläuft.

Abb. 1: Bei Debuggingproblemen wird in Visual Studio ein Break ausgelöst

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -