locked
Binding expression error RRS feed

  • Question

  • I'm getting a binding expression error on one of my custom controls ... I see the error in my debug output window.  Basically I'm using a trigger to check back to the ancestor object for a property setting and then setting some property if there's a true or false value.  The problem is that my control in theory could be used by itself on a Window and not have the parent ancestor object ... so hence the binding expression error occurs in that case.

    What's the best way to handle this situation?  I want to check back to an ancestor object for a value - but if that ancestor object doesn't exist, how can I check for that first in my trigger?
    Monday, February 8, 2010 6:33 PM

Answers

  • There's certainly some validity to that.  The cost, however, really depends on the scenario... the binding resolution typically only occurs when the element tree is connected, so if this particular UI is only created once (or at least minimally), then you will only gain a small perf benefit by avoiding the situation.  If the UI comes and goes a lot, it might be worth further investigation.

    Of course, there's only so much that can be done to avoid the situation you describe.  If the ancestor binding is required whenever the ancestor exists, the only way to really know its valid is to walk the tree.  Whether you do this yourself or rely on the binding engine really isn't going to make much difference.
    Dr. WPF - Online Office at http://drwpf.com/blog/
    Monday, February 8, 2010 11:36 PM

All replies

  • The debug output can be misleading.  It does not necessarily mean there is a problem.  Is there an undesired side effect of not finding the ancestor (other than the debug output)?

    In general, I do not worry about binding exceptions unless they are causing a problem.  They are silently swallowed for good reason.  There are plenty of cases where a binding may not resolve at one point but later it does.

    If there's an actual problem, then that is a different story.  In that case, please describe the specific unwanted behavior that occurs when the control does not have the ancestor in question.  Note that the solution may involve writing code within the control to walk the ancestor tree manually.
    Dr. WPF - Online Office at http://drwpf.com/blog/
    Monday, February 8, 2010 7:20 PM
  • There isn't really a behavioral problem, however we are actively trying to fine tune performance as much as possible.  The popular thought seems to be that data binding errors can cause a performance hit - so we're trying to get rid of all those errors as performance is extremely important.
    Monday, February 8, 2010 10:00 PM
  • There's certainly some validity to that.  The cost, however, really depends on the scenario... the binding resolution typically only occurs when the element tree is connected, so if this particular UI is only created once (or at least minimally), then you will only gain a small perf benefit by avoiding the situation.  If the UI comes and goes a lot, it might be worth further investigation.

    Of course, there's only so much that can be done to avoid the situation you describe.  If the ancestor binding is required whenever the ancestor exists, the only way to really know its valid is to walk the tree.  Whether you do this yourself or rely on the binding engine really isn't going to make much difference.
    Dr. WPF - Online Office at http://drwpf.com/blog/
    Monday, February 8, 2010 11:36 PM