Thursday, September 9, 2010

Debugging Data Bindings in a WPF or Silverlight Application - WPF & Silverlight Designer - Site Home - MSDN Blogs

Debugging Data Bindings in a WPF or Silverlight Application

The WPF and Silverlight platforms use late bound data binding resolution for bindings in XAML files. This feature allows a DataContext to be set at run-time and the objects within that DataContext to resolve their property bindings then. This late binding enables cool features like DataTemplates, composable applications and run-time loading of loose XAML.

A side effect of late bound binding resolution that can cause developers some minor frustration is that their controls do not display the expected data at run-time.

This article will explain troubleshooting techniques that can help you locate and correct the problem.

Data Binding Overview

Data binding is fundamental to WPF and Silverlight. You will struggle with your application designs, coding and troubleshooting until you understand data binding in these platforms.

The best data binding resource available is the MSDN Data Binding Overview topic. If you have not read or don't fully understand the material in this topic, please take the required amount of time to learn this material.

Ounce of Prevention is Worth a Pound of Cure

Visual Studio 2010 has great tooling to wire up data bindings and checked them at design-time. Please read this article: How to Enable Using the Binding Builder in WPF and Silverlight Applications.

Visual Studio 2010 has excellent design-time sample data support. If you use design-time sample data, you'll immediately see controls that don't have expected data values at design-time.

For a detailed examination of sample data in the WPF and Silverlight Designer for Visual Studio 2010, please read this article: Sample Data in the WPF and Silverlight Designer.

Troubleshooting List

  • Verify that DataContext is set in either XAML or code
  • Run the application and view the output in the Debug Output Window
    • For WPF applications you can increase or decrease the amount of information displayed in the Debug Output Window by changing the WPF Trace Settings, Data Binding value
  • Name the control that has DataContext assigned, set a break point in the code, and view the named control's DataContext property in the debugger
  • If binding to a CLR object, put a breakpoint in the source property getter to see that its actually being queried
  • Add a converter to a binding, then put a breakpoint in the converter

Verify that DataContext is set in either XAML or Code

This tip is along the lines of, "if the TV won't turn on, check that it's plugged in."

This is important for many reasons, but one is easily overlooked; if a DataContext is null, the Debug Output Window will not display any error messages in Silverlight or in WPF.

In WPF you can use the below PresentationTraceSources on a binding and set the TraceLevel to High to view errors related to a null DataContext.

View the Debug Output Window

If you have the DataContext set, any data bindings within that DataContext that can't be resolved will be listed in the Debug Output Window at run-time.

Sample Debug Output Window Data Binding Error

Sample One

System.Windows.Data Error: 40 : BindingExpression path error: 'FirstName' property not found on 'object' ''Object' (HashCode=62178992)'. BindingExpression:Path=FirstName; DataItem='Object' (HashCode=62178992); target element is 'TextBox' (Name=''); target property is 'Text' (type 'String')

Sample Two

System.Windows.Data Error: 40 : BindingExpression path error: 'FirstName' property not found on 'object' ''Customer' (HashCode=13640894)'. BindingExpression:Path=FirstName; DataItem='Customer' (HashCode=13640894); target element is 'TextBox' (Name=''); target property is 'Tag' (type 'Object')

While the above messages look verbose and complex, you can glean several interesting points of information that will help you correct this data binding:

  • The Binding Path is FirstName. Search your XAML file for FirstName and see if you expect the DataContext to expose a FirstName property whose scope will allow this binding to resolve this property.
  • The Source object in Sample One is of Type Object. There is a good chance the Type Object does not have a FirstName property.
  • The Source object in Sample Two is of Type Customer. Check your Customer Type; does it have a FirstName property?
  • Notice in Sample Two, the target property is Tag. In all likelihood, the Text property was the desired target property and not Tag. Also the Type of Tag is Object; you would probably be expecting String when binding to the FirstName property.

Review

  • Verify the property name is spelled correctly
  • Verify the property name has the correct character casing. FirstName is not the same as firstName.
  • Verify the property is a member of the DataContext Type
  • Verify the target element is the correct Type
  • Verify the target property name and Type are correct

Posted via email from Mocha Brain Freeze

No comments: