While trying to answer a question in the vicinity 'Unit Testing WPF Bindings' I had the following niggling question..
What's the best way to find if you have WPF Data Binding wiring setup incorrectly (or you just broke something that was wired up correctly) ?
Although the unit-testing approach seems to be like Joel's 'ripping off your arm to remove a splinter'.. I am looking around for easier less Overhead ways to detect this.
Everyone seems to have committed themselves to data binding in a big way with WPF.. and it does have its merits.
This was very helpful to us but I wanted to add to those who find this useful that there is a utility that Microsoft provides with the sdk to read this file.
Found here: http://msdn.microsoft.com/en-us/library/ms732023.aspx
Also, as for the filtering of the log file, we found these this link extremely helpful:
http://msdn.microsoft.com/en-us/library/ms751526.aspx
You can use the trigger debugging feature of WPF Inspector. Just download the tool from codeplex and attach it to your running app. It also shows binding errors on the bottom of the window. Very useful tool!
Here's a useful technique for debugging/tracing triggers effectively. It allows you to log all trigger actions along with the element being acted upon:
http://www.wpfmentor.com/2009/01/how-to-debug-triggers-using-trigger.html
In .NET 3.5 it was introduced a new way to specifically output tracing information about specific data bindings.
This is done through the new System.Diagnostics.PresentationTraceSources.TraceLevel attached property that you can apply to any binding or data provider. Here is an example:
This will put trace information for just that particular binding in Visual Studio's Output Window, without any tracing configuration required.
I use the solution presented here to turn binding errors into native Exceptions: http://www.jasonbock.net/jb/Default.aspx?blog=entry.0f221e047de740ee90722b248933a28d
However, a normal scenario in WPF bindings is to throw exceptions in case the user input cannot be converted to the target type (for instance, a TextBox bound to a integer field; the input of a non-numeric string results in a FormatException, the input of number that is too large results in an OverflowException). A similar case is when the Setter of the source property throws an exception.
The WPF way of handling this is via ValidatesOnExceptions=true and ValidationExceptionRule to signal the user the supplied input is not correct (using the exception message).
However, these exception are also send to the output window and thus 'caught' by the BindingListener, resulting in an error...clearly not the behaviour you'd want.
Therefore, I expanded the
BindingListener
class to NOT throw an Exception in these cases:Modified lines in public override void WriteLine(string message):
For anyone like me looking for a pure programmatic way of enabling all WPF Tracing at a given Trace Level, here is a piece of code that does it. For reference, it's based on this article: Trace sources in WPF.
It doesn't requires a change in the app.config file, and it does not require to change the registry either.
This is how I use it, in some startup place (App, etc.):
And here is the utility code (by default it sends all Warning to the Default Trace Listener):