Every so often I find that I have accidentally broken data binding in my application. Either by renaming a property and not renaming it in the XAML or by a property throwin
Have a look at this blog article which may help get around this issue.
After some procrastination I finally set about coding a solution to my original issue.
My solution uses a custom TraceListener (originally suggested by John) that logs to an output window. The output window is automatically displayed and bought to the foreground when an error occurs.
Here is my TraceListener:
public class ErrorLogTraceListener : TraceListener
{
public override void Write(string message)
{
...
}
public override void WriteLine(string message)
{
...
}
}
TraceListener is defined in System.Diagnostics.
The custom TraceListener must be hooked into the system to be used. The official way to do this is to set something in the registry and then use the App.config file to configure the TraceListener.
However I found that there is a much easier way to do this programmatically:
ErrorLogTraceListener listener = new ErrorLogTraceListener();
PresentationTraceSources.Refresh();
PresentationTraceSources.DataBindingSource.Listeners.Add(listener);
PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Error;
PresentationTraceSources is also defined in System.Diagnostics.
For more information on trace sources see Mike Hillberg's blog.
Bea Stollnitz has some useful info on her blog.
Raising binding exceptions in WPF & Silverlight with .net 4.0 Dynamics.
I implemented a solution very similar to the accepted answer:
TraceListener that throws instead of loggingPresentationTraceSources.DataBindingSourcePlease see the complete solution on GitHub, it includes a demo application and a unit test project.
