Skip to main content

Debugging databinding failures in WPF

WPF has a great databinding support but when it does not work it can be hard to debug. Understanding of databinding model in WPF can go a long way in making data binding easy. Since working on WPF i myself have faced "binding not working" syndrome. The general tendency then is to revert back to the code behind approach which does not look clean at all. In all cases its our lack of understanding of binding model or incorrect usage of binding the main culprit. In this post i would try to create a checklist which can be used to systematically debug any specific binding issue. But before reading this i would highly recommend that every WPF developer should thoroughly try to understand the WPF binding by going over the MSDN documentation and other sources. The steps mentioned here would make more sense if we have a clear understanding of databinding. We would be tacking the most common situation where a frontend UI is bounded to a backing entity.

  • Is the binding setup correctly (Binding is failing) : Misspelled names, incorrect DataContext can be first culprit for binding not working. This can be determined by looking at the output window while debugging the application. Each failing binding would be logged in the output window. Remember databinding are reevaluated anytime DataContext changes. If you are setting up DataContext in code, look for binding failure just after DataContext is assigned. Some of the most common reason for binding failures are
    • Misspelled member variable names. Very easy to detect
    • Incorrectly declare a Public property as Public field (no get;set;). AFAIK databinding works only on public properties
    • Declaring member as internal or with more restricted accessors.
    • Using incorrect DataContext. DataContext assigned at parent control level can directly affect the DataContext of a child control if child is not bounded to a specific DataContext explicitly. Therefore any parent DataContext change can invalidate the child control binding.
  • Binding not failing but data not getting updated: There can be numerous reasons for this. You may not see any binding failures in the output window specific to your binding but neither the source or target are getting updated. Some of the most common reason for this is
    • Binding mode may be incorrect. Check documentation for binding mode and use a appropriate binding accordingly.
    • Check for UpdateSourceTrigger Property of binding is setup correctly.
    • Value being assigned from source to target or vice versa is incompatible. You can use a debugging converter to see what values are being passed from source to target. More details about this are available on this blog entry.
    • Does the binding contain any validation rules. In case binding contains validation rules, any update on target( mostly UI element) will reevaluate the rule and if the rule fails source(entity) would not be update.
    • Incorrect DataContext assignment. This is a little difficult to find. Make sure that the DataContext used in databinding is pointing to the correct entity (or source). You may be expecting a different source to be updated and you have done databinding to a different source. DataContext assignments in code should be thoroughly evaluated.

Hope this list may help everyone debug their databinding issues. Some the stuff here is derived from an excellent blog entry by Bea Stollnitz

Thanks,
Chandermani

Comments

Popular posts from this blog

Caching Images downloaded from web on Windows Phone Isolated storage

I was helping on a Windows Phone application where the requirement was to cache the images the phone downloads on the isolated storage for offline viewing.
I wanted a solution which was simple and as transparent as possible. While researching I found  someone wrote a Silverlight converter for loading images from isolated storage. Taking that as a base I created a converted which can
Load image from web (http + https), and persist it to isolated storage.In case of network connectivity issues can load the same image from isolated storage. It does that by mapping the http url to a isolated storage location.In case the network is down and the image is neither there in cache, loads a default image, passed as parameter to converter.Here is the gist for the implementation.


To use the converter
Import the name space.Declare the converter as resource.Set the Image Source Property to use this converter like this 

IIS Url Rewrite and HTTP POST data

If you play around with IIS Url Rewriting rules and try to do redirects on an HTTP POST you loose your POST data.

To make sure you get the post data you have to set the `redirectType` to `Temporary` within your rules. So the action configuration looks like this

<action redirectType="Temporary" type="Redirect" url="http://{HTTP_HOST}{REQUEST_URI}"> </action>
You may think what scenario warrant a POST request redirect. We faced one such scenario while doing SSO with a federated Identity Provider (IP)  such as Google, Azure AD. In federated authentication scenario once the user is authenticated by the IP, it redirects back to your site with claim tokens in a POST request over secure channel (https). In our case we wanted to redirect to user back http after receiving the request. But any redirects were causing loss of token. By doing a 307 (Temporary) redirect we were able to preserve the post data.