No, it’s not possible to handle exceptions from the rendering thread, but I never came across a scenario that required it. The rendering thread contains native code that is responsible only for the actual rendering of the app, it doesn’t not contain any user code. I never encountered an exception thrown in the rendering thread.

The scenario you describe is executed on the UI threaad. You should be able to catch exceptions on the UI thread as usual (try/catch).

Bea

That is strange – it never happened to me. Data binding debugging messages should just show up in the output window, both in WPF and Silverlight.
You mentioned the “Immediate Window” – please keep in mind that the debug messages show up in the “Output Window”.

Bea

> I can’t find any documentation to say tell me if this would only be effective in a debug build, presumably not – can anyone confirm?
Tracing is actually not a WPF feature – it was around in .NET before WPF used it. From what I could understand in the MSDN documentation, Trace output happens for both debug and release builds. This should be easy for you to try with your application – is this what you see?
There may be better ways to avoid debug output from being generated in release builds, but you can always wrap the trace listener code you show above with an #if DEBUG.

> And if it is effective regardless of the build then is it going to have a performance impact?
Yes, it will certainly affect performance.

> Also – would a knock on effect of this be that anything less than SourceLevels.Error would not got to any trace listener?
That is correct.

Bea

WpfTraceListener traceListener = new WpfTraceListener();

PresentationTraceSources.Refresh();
PresentationTraceSources.DataBindingSource.Listeners.Add(traceListener);
PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Error;

and the WpfTraceListener.WriteLine shows the message parameter in our Error dialog.

I can’t find any documentation to say tell me if this would only be effective in a debug build, presumably not – can anyone confirm?
And if it is effective regardless of the build then is it going to have a performance impact?
Also – would a knock on effect of this be that anything less than SourceLevels.Error would not got to any trace listener?

Basically I feel backed into a corner and want to know if it is reasonable to do what I have done.
* If I don’t do the above then any exceptions which don’t get noticed during development – either because someone’s eye was not on the Output window or because the exception condition never arose – will not surface in any immediately obvious way during use of the release version of the application.
* If I include the code above will my application be punished with poorer performance?

Pete.

I have Brandon’s problem! There were some databinding messages from a previous run in my Immediate window, but now NONE get written there. The only diag info shown is the Silverlight loading messages.

I resent the profile to the General Dev. defaults to make sure I hadn’t kicked something off accidentally…. still no debugging messages at all.

Help! :-)

Thanks,
– D

There is no special setup for the binding debug messages to appear in the output window – they just show up there. I haven’t tried your scenario, but yes, it’s possible that they don’t come up because you’re using ElementHost. Maybe you can try the trace source or trace level debugging solutions?

Bea

Could this be because I’m working on an Office plugin (VSTO) with WPF controls embedded in an ElementHost? Or is there something else I’m not enabling?

I have turned on PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Verbose;

Brandon