-2

I'm trying to get WPF databinding errors to display in the Output window. None of the suggestions found here have helped, nor here.

Is there anything else I might try?

InteXX
  • 6,135
  • 6
  • 43
  • 80
  • What exactly do you mean? The default behaviour outputs errors for failed bindings. – Andy Jul 10 '20 at 17:08
  • That's what I'm to understand. For some reason, however, it's not doing that for me. It was a comment in [this Q&A](https://stackoverflow.com/q/62825701) that brought it to my attention that we were even supposed to see it at all. – InteXX Jul 10 '20 at 18:49
  • Tell us more about your app. In a totally new solution. Add a textbox and a binding for it's text property to foo. Hit f5. No databinding failure in the output window? – Andy Jul 11 '20 at 11:01
  • `Tell us more about your app` It's pretty simple so far. You can see it [here](https://stackoverflow.com/q/62825701). `Add a textbox and a binding ... to foo` Done. Brand new solution. Same result. Not a peep. – InteXX Jul 11 '20 at 14:28
  • This is visual studio then. Seems you've somehow got first chance exceptions entirely switched off. You could try resetting to default. I think the comand line switches listed here still apply. https://stackoverflow.com/questions/17203820/how-do-i-truly-reset-every-setting-in-visual-studio-2012 – Andy Jul 11 '20 at 15:02
  • Thanks for the link. I'm guessing it's possible to enable that without losing my entire environment, which I've crafted over time with love :-) I'm reading [this](https://preview.tinyurl.com/vzmef4e) and [this](https://preview.tinyurl.com/yda6r7xh), which together seem to indicate so. True, the discussion revolves around the concept of breaking, not sending to the output window, but perhaps you might share the exception type that you're getting and I could try enabling it? In my current config, only four in that long list of CLR exceptions are enabled. – InteXX Jul 12 '20 at 01:56
  • Another resource to be aware of: [The Stack Overflow WPF Chat Room](https://chat.stackoverflow.com/rooms/18165/wpf) – Lynn Crumbling Jul 14 '20 at 19:42
  • Thank you Lynn, I'll have a look | @LynnCrumbling – InteXX Jul 14 '20 at 20:22
  • What I do is add this SetTracing method of my own at startup time (for example in App ctor), and that's it (not only for binding errors BTW): https://pastebin.com/raw/EdzW3bCZ now when you press F5, you should see binding errors in VS's output window. (Note: if DataContext is null, no errors are generated, so to test it you must set it to anything but null) – Simon Mourier Jul 15 '20 at 17:29
  • I was excited to see this at first, but alas it doesn't help. I really like the idea, but still no binding errors are showing up in the output window. Here's my [XAML](https://stackoverflow.com/q/62825701). As noted I figured out the problem (case sensitivity in XAML and my mistyped method name), but when I set it back to the wrong casing—and verify that it doesn't work—no binding errors are displayed. | @SimonMourier – InteXX Jul 18 '20 at 01:12
  • It works for me for years. Make sure you're debugging (F5) and are you sure you even have errors reported? Try to set the level of SetTracing to verbose or information. At this level , something is always shown in VS' output window. If it doesn't work, post a full reproducing/compiling project somewhere so we can have a look – Simon Mourier Jul 18 '20 at 09:40
  • Strange things are afoot. See my comment on Andy's answer. | @SimonMourier – InteXX Jul 18 '20 at 20:48

2 Answers2

1

Your problem seems to be caused by your settings.

Which is why I suggested you return your install to default settings. Since you don't want to do that then it's a case of working out which part you changed to stop this working.

These are first chance exceptions you're not seeing. And, obviously, they are wpf binding specifically.

There are a number of ways someone could break this functionality.

There is an option you can set in code. This would be in app.xaml.cs or mainwindow ctor. Seeing as this happens in a brand new clean solution then I should think this is unlikely unless you're somehow getting this in there:

 System.Diagnostics.PresentationTraceSources.DataBindingSource.Switch.Level = 
System.Diagnostics.SourceLevels.Critical;

That'd simply filter out all databinding failures.

There's also Tools > Options > Debugging > Output Window

In there you will see the settings for the output window. It ought to look like:

WPF Trace settings

You can also set options on the output window itself. Right click it and on the context menu there are a bunch of checkable options. Top of which is Exception Messages. If that isn't ticked then tick it. This particular checkbox will send first chance exceptions to the immediate window if unchecked.

see https://learn.microsoft.com/en-us/visualstudio/ide/reference/immediate-window?view=vs-2019#first-chance-exception-notifications

First-chance exception notifications

In some settings configurations, first-chance exception notifications are displayed in the Immediate window.

Toggle first-chance exception notifications in the Immediate window On the View menu, click Other Windows, and click Output.

Right-click on the text area of the Output window, and then select or deselect Exception Messages.

There is also an outside chance you've got a plug in or something which is interfering. For example, the preview xaml binding failures plugin.

If all else fails you might want to try that.

https://marketplace.visualstudio.com/items?itemName=PeterSpa.XamlBinding

This is still experimental, but if your install is somehow subtly broken then you're not going to get any worse than totally missing binding failures.

Andy
  • 11,864
  • 2
  • 17
  • 20
  • I tried everything: 1) Startup switches 2) Deleted registry keys 3) Deleted `%LocalAppData%` folders 4) Snoop [see my comment in the other answer] 5) Marketplace extension 6) Exception settings 7) Output window options 8) Adjusting my tongue in my cheek 9) Standing on my head. Nothing helped. Then, by an absolute fluke, I happened to notice that binding errors are being sent to the *Immediate* window, not Output. I have no way of knowing whether this was happening before I tore the guts out of my setup. – InteXX Jul 18 '20 at 20:46
  • You went to a lot of trouble to accommodate my persnicketiness and composed a damn fine answer. I believe that calls for a bonus award. – InteXX Jul 18 '20 at 22:00
  • Thanks for the edit. I tried that just now—had tried it earlier as well—but still no luck. Binding errors are still going to the Immediate Window. But that's OK with me if it's OK with you. At least I can see 'em. I can live with that. – InteXX Jul 19 '20 at 15:34
  • You closed vs down and re-opened after the change? It's dis-satisfying not having an absolute fix but this works for me so you have something else interfering. I suppose it's an advantage in a way. Assuming you don't use the immediate window so much then having the errors appear there makes them easier to find. – Andy Jul 19 '20 at 15:38
  • Actually, there was no change. Exceptions were already selected. Good point on the advantage—I was thinking pretty much the same thing. If I start to get quirky behavior in my app that hints at a binding error, I can just go to the IW. Thanks again. – InteXX Jul 19 '20 at 16:34
0

If your objective is to view the databinding errors only for debugging purposes, and you are having trouble with setting it up, I would suggest use of an alternate tool: The Snoop tool. Very useful tool with a small learning curve. It is extremely useful for other situations as well.

Wpf Snoop

Usage to view binding errors

Aabid Ali
  • 109
  • 2
  • 13
  • Oddly, nothing shows up in Snoop either. But don't we have to catch the exceptions as they occur? By the time we attach Snoop, those exceptions are long gone. Here's my [XAML](https://stackoverflow.com/q/62825701) and the problem I'm trying to troubleshoot. – InteXX Jul 18 '20 at 01:19