Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / desktop / WPF

Don’t Move or I Will Shoot Your Bindings

4.27/5 (3 votes)
29 Mar 2011CPOL1 min read 12.6K  
How WPF binding systems sometimes fail silently.

WPF bindings and MVVM are nice when they work, but can become a royal pain when they don’t. This is especially annoying when you create bindings in code, because then you don’t get the automatic tracing which is enabled for bindings in XAML. Any error is silently swallowed. Here’s what I found out (waiting to confirm it with MSDN documentation and independent small tests):



  • if you have a one-way binding and someone changes the target value not using the binding, the binding will be deactivated.
  • if you have a two-way binding, someone changes the target value not using the binding, and something goes wrong updating the source (e.g., converter’s ConvertBack() method throws an exception), your binding will be deactivated.

Deactivated bindings look like they are there, but they don’t do anything. Effectively, binding stops working, and it is often very difficult to know exactly why. If you created the binding in code, you can look at the status of the binding expression. If you created the binding in XAML, getting to its status is much more difficult. Also, it is not possible (to the best of my knowledge) to put a breakpoint when binding status changes: there is no data breakpoints in managed code, and I could not get .NET source debugging to work for WPF bindings for whatever reason. I could see things like DependencyObject, but not BindingOperations.


Bottom line: binding systems sometimes fail silently. Detecting and debugging those failures can be very time consuming and difficult.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)