Debugging WPF events, bindings

Question

What method do you use when debugging WPF events or bindings?

I tried to use breakpoint, but it seems like that something's wrong with my XAML or behind the code that it never hits the breakpoint.

Is there a way to see when I click something in WPF, what event messages are popping up or not popping up to understand what went wrong?

Answer 1

In last 3 years of building WPF applications almost full-time I have collected a variety of reactive and preventative solutions to ensure that everything binds together properly.

Note: I will give you a quick summary now and then post back in the morning (in 10 hours time) with code samples / screenshots.

These are my most effective tools:

1) Create a converter that breaks the debugger when the Convert and ConvertBack is executed. A quick and useful way to ensure that you have the values that you expect. I first learnt of this trick from Bea Stollnitz's blog post.

DebugConverter.cs

public class DebugConverter : IValueConverter
{

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        if (Debugger.IsAttached)
            Debugger.Break();

        return Binding.DoNothing;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        if (Debugger.IsAttached)
            Debugger.Break();

        return Binding.DoNothing;
    }

}

2) Create a TraceListener that intercepts any errors. This is similar to what you see in the Visual Studio Output Window when you have a debugger attached. Using this method I can get the debugger to break when there is a exception thrown during a binding operation. This is better than setting PresentationTraceSources.TraceLevel as it applies to the entire application, not per-binding.

DataBindingErrorLogger.cs

public class DataBindingErrorLogger : DefaultTraceListener, IDisposable
{
    private ILogger Logger;

    public DataBindingErrorLogger(ILogger logger, SourceLevels level)
    {
        Logger = logger;

        PresentationTraceSources.Refresh();
        PresentationTraceSources.DataBindingSource.Listeners.Add(this);
        PresentationTraceSources.DataBindingSource.Switch.Level = level;
    }

    public override void Write(string message)
    {
    }

    public override void WriteLine(string message)
    {
        Logger.BindingError(message);

        if (Debugger.IsAttached && message.Contains("Exception"))
            Debugger.Break();
    }

    protected override void Dispose(bool disposing)
    {
        Flush();
        Close();

        PresentationTraceSources.DataBindingSource.Listeners.Remove(this);
    }

}

Usage

DataBindingErrorLogger = new DataBindingErrorLogger(Logger, SourceLevels.Warning);

In the above, ILogger is an NLog log writer. I have a more complex version of DefaultTraceListener that can report a full stack trace and actually throw exceptions however this will be enough to get you started (Jason Bock has an article on this extended implementation if you want to implement it yourself, although you will need code to actually to get it work).

3) Use the Snoop WPF introspection tool to delve into your view and inspect your data objects. Using Snoop you can view the logical structure of your view and interactively change values to test different conditions.

Snoop WPF is absolutely essential to the iteration time of any WPF application. Among its many features, the Delve command allows you to drill down to your view/view model and interactively tweak values. To delve into a property, right-click to open the context menu and select Delve command; to go back up a level (un-delve?) there is a small button ^ in the top-right corner. For example, try delving into the DataContext property.

Edit: I can't believe I just noticed this, however there is a Data Context tab in the Snoop WPF window.

4) Runtime checks on INotifyPropertyChanged events in #DEBUG. As the Data Binding system relies on being notified when properties have changed, it is important for your sanity that you are notifying that the correct property has changed. With a bit of reflection magic you can Debug.Assert when something is wrong.

PropertyChangedHelper.cs

public static class PropertyChangedHelper
{
    #if DEBUG
    public static Dictionary<Type, Dictionary<string, bool>> PropertyCache = new Dictionary<Type, Dictionary<string, bool>>();
    #endif

    [DebuggerStepThrough]
    public static void Notify(this INotifyPropertyChanged sender, PropertyChangedEventHandler eventHandler, string propertyName)
    {
        sender.Notify(eventHandler, new PropertyChangedEventArgs(propertyName), true);
    }

    [DebuggerStepThrough]
    public static void Notify(this INotifyPropertyChanged sender, PropertyChangedEventHandler eventHandler, string propertyName, bool validatePropertyName)
    {
        sender.Notify(eventHandler, new PropertyChangedEventArgs(propertyName), validatePropertyName);
    }

    [DebuggerStepThrough]
    public static void Notify(this INotifyPropertyChanged sender, PropertyChangedEventHandler eventHandler, PropertyChangedEventArgs eventArgs)
    {
        sender.Notify(eventHandler, eventArgs, true);
    }

    [DebuggerStepThrough]
    public static void Notify(this INotifyPropertyChanged sender, PropertyChangedEventHandler eventHandler, PropertyChangedEventArgs eventArgs, bool validatePropertyName)
    {
        #if DEBUG
        if (validatePropertyName)
            Debug.Assert(PropertyExists(sender as object, eventArgs.PropertyName), String.Format("Property: {0} does not exist on type: {1}", eventArgs.PropertyName, sender.GetType().ToString()));
        #endif

        // as the event handlers is a parameter is actually somewhat "thread safe"
        // http://blogs.msdn.com/b/ericlippert/archive/2009/04/29/events-and-races.aspx
        if (eventHandler != null)
            eventHandler(sender, eventArgs);
    }

    #if DEBUG
    [DebuggerStepThrough]
    public static bool PropertyExists(object sender, string propertyName)
    {
        // we do not check validity of dynamic classes. it is possible, however since they're dynamic we couldn't cache them anyway.
        if (sender is ICustomTypeDescriptor)
            return true;

        var senderType = sender.GetType();     
        if (!PropertyCache.ContainsKey(senderType))
            PropertyCache.Add(senderType, new Dictionary<string,bool>());

        lock (PropertyCache)
        {
            if (!(PropertyCache[senderType].ContainsKey(propertyName)))
            {
                var hasPropertyByName = (senderType.GetProperty(propertyName, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Static) != null);
                PropertyCache[senderType].Add(propertyName, hasPropertyByName);
            }
        }

        return PropertyCache[senderType][propertyName];
    }
    #endif

}

HTH,

Answer 2

Adding a "pass-through" converter on a binding can sometimes help by allowing you to put a break point in the converter that will get pulled when ever there is a binding update. It also allows you see the values being passing both ways through the binding from Convert and ConvertBack value parameter.

public class PassthroughConverter : IValueConverter {
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture) {
        return value; // Breakpoint here.
    }
    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) {
        return value; // Breakpoint here.
    }
}

If you can access a control by Name then in your Window.xaml.cs you can check the state of bindings on the control using:

BindingExpression be = comboMyCombo.GetBindingExpression(ComboBox.IsEnabledProperty);  

looking at 'be' in the debugger can help (sometimes the bindings get reset/broken on certain operations).