I've read a lot of questions on SOF and links (for example http://www.beacosta.com/blog/?p=52)
But is there easy way to know what exact file I should look into when Binding fails?
If we have one Application and a lot of forms, it can be difficult too.
Have you tried checking "Thrown" for the exception in question in the Debug->Exceptions menu.
E.g. if you get
System.Windows.Data Error: 35 : BindingExpression path error ...
Then you can tell the debugger to break on it by checking "Thrown" under Common Language Runtime Exceptions -> System.Data -> System.DataException. This is however, only useful if the exception originally occurs in your code. Other exceptions, such as binding to non-existing properties and so on will silently fail and only print in the Output window. There is some discussion on http://visualstudio.uservoice.com for improving XAML debugging
I just found the most WONDERFUL post when looking for this. It is a listener that listens for binding errors and throws up a message box with details. It only works when running from within Visual Studio, so you won't show it to your users. Two steps - copy the class into your project, and set the listener in your main window.
http://tech.pro/tutorial/940/wpf-snippet-detecting-binding-errors
You can use Snoop for this: http://snoopwpf.codeplex.com/
Just use Snoop to point to your application and then you can sort on Binding Errors. All Bindings Errors will be highlighted in RED, and show the property of the control.
Related
Is there a way to see which UserControl/Window/etc is being instantiated when these errors are happening?
A typical error looks like this:
System.Windows.Data Error: 40 : BindingExpression path error: 'BackgroundColor' property not found on 'object' ''MapContainerViewModel' (HashCode=25350572)'. BindingExpression:Path=BackgroundColor; DataItem='MapContainerViewModel' (HashCode=25350572); target element is 'SolidColorBrush' (HashCode=35109313); target property is 'Color' (type 'Color')
Problem? Where is it happening? In which XAML file? In which class?
Doesn't it seem bizarre that you get a list of symptoms, but not the patient's name?
In a small project I would probably know where to look. I'm currently refactoring an MVVM project with hundreds of Windows/UserControls, many of which have similar looking Binding Paths.
So I have to do an "Entire Solution" search for the property names and come up with a list of candidates (UserControls/Windows) that may have caused the Binding error when they were instantiated.
Another option would be to have Visual Studio break and show me the XAML as soon as a System.Windows.Data error occurs. Following tutorials like this one, I can get the code to break--but it doesn't indicate any XAML or class name. The stack trace shows nothing--as the controls are being automatically created via MEF.
Thanks for any help.
Chad.
UPDATED:
Live Visual Tree doesn't work in this case, because the UserControls/Windows in question are sitting in an MEF container and aren't attached.
Any visual approach won't work because the views/datacontexts (view models, in this case) were instantiated via MEF (DI pattern) and are waiting to be added to the visual tree.
The debugger is not going to help you very much with XAML. This is because XAML is declarative while the debugger is designed for imperative code. For WPF you need to rely on a different tool set, specifically the Live Visual Tree and the Live Property Explorer in VS2017.
Here is a simple WPF app with a few textbox controls.
One of the text box controls is not working. How do I find it? First open the Live visual tree. Click the enable selection button in the WPF tool bar (the second button). Then select the control which is not working. The live visual tree will select the control.
Now select the TextBox parent control in the Live Visual Tree (FirstValueField). Now open the Live Property Explorer.
Note the yellow box around the Text property. This is where the error is. Click to the right of the property field and select "Go To Source".
So here is where the error is. You can see where I changed the code to introduce the error.
This is the general approach to debugging WPF, XAML or any declarative code: (1) give up on the debugger...it will simply get in the way; (2) learn how to use the fit-for-purpose tools to find errors; (3) if that doesn't work, use print statements.
In my experience the WPF tools are excellent for finding common errors. The more complex your WPF becomes however, the more you will need to embed code to diagnose and identify the problem.
I'm trying to create a custom control using UserControl. When I drop the custom control on a window, it displays for a second then the designer crashes and I get the messag:
An Exception was thrown
ArgumentNullException: Value cannot be null.
Parameter name: sp
The stack trace shows an error in a call the ServiceProvider constructor.
Any idea what's going on on here? I tried this with a blank UserControl on a blank Window and got the same error.
Thanks for your help.
XAML designer will call the UserControl's constructor when loading in designer.
If in the constructor or UserControl.Loaded is another Method that is not running in the design mode should be skip.
In order to avoid this you can place a if condition as follows in your UserControl constructor
if(DesignerProperties.GetIsInDesignMode(this))
return;
// another Method that Running in RunTime
WPF user control throws design-time exception
After further googling the issue, it seems that this is related to the presence of installshield projects in the solution. If I remove all installshield projects, I don't get the exception anymore.
This is more of a workaround than a solution though...
Referring to this question and this question, the solutions in the accepted answers are working, but in the project i want to apply, no binding or trigger is working. There is no error, the triggers etc simply do not respond.
The code is huge, with a complicated layout using many grids and panels and a ribbon. Source of binding and triggers and target are in different panels (source in ribbon, target in grid below). I know the code is correct, my question is:
What is the checklist? What are the things i need to look at to ensure that triggers and bindings are working.
If source and target are in different panels, is there something different in their implementation (like going from ribbon to the parent (main grid created by default)) and then finding the target in the children (grid)?
I can print on console if i write code-behind, but is there a way to debug triggers and bindings?
You can always look i your output window for binding failures. This might prove helpful to you to test your bindings and trigger failures -
http://bea.stollnitz.com/blog/index.php?s=presentationtrace
I've also had success debugging triggers with this technique:
http://www.wpfmentor.com/2009/01/how-to-debug-triggers-using-trigger.html
I'm using Visual Studio 2010 to create a small WPF application. I've created a user control that I am now trying to add to my main form. The user control does show up in toolbox but every time I try to drag the control to the form I get the error:
The enumerator is not valid because the collection changed.
I should know what's wrong and it is bugging me that I can't figure it out.
You have a bug in the constructor of the usercontrol - you are using a foreach-loop over an IEnumerable and while the loop is running, the IEnumerable is changed, this is not allowed with a foreach loop. Use a for loop instead if you are manipulating the Collection you are iterating over.
The problem here is that you don't know what code is throwing the exception.
WPF is terrible about exceptions, especially in constructors. The framework insists on catching and re-throwing a new exception, usually multiple times, and it's difficult to find the original stack trace. I've found the easiest way to track down this kind of error is to tell Visual Studio to stop as soon as the exception is thrown, rather than waiting until WPF has re-thrown it a couple of times and made the details difficult to dig out.
I don't have Visual Studio 2010 in front of me, but here's how to do this in VS2008 -- 2010 is probably similar:
Go to the Debug menu > Exceptions...
Next to "Common Runtime Language Exceptions", check the box in the "Thrown" column
Then debug your app again. It will stop at the line that's actually causing the problem, and it'll be much easier for you to see what's going on. And if you're still not sure why it's throwing an exception, you'll be able to post a code sample.
In order for a user control to function properly you need to have a constructor that takes zero arguments. This way the form designer has a way to render the control in a "default" manner.
I then overloaded my constructor to take the arguments I needed to actually run the control properly and everything worked as expected.
You need to:
Remove the DLL reference
Add a reference to your control
Rebuild the solution
Add your control. It should work!
when we bind to heterogeneous collection of objects, not all objects have the same set of properties. in the output window we get a message like:
System.Windows.Data Error: 39 :
BindingExpression path error:
'RoundingFactor' property not found on
'object' ''MultiLineTextMarkingScheme'
(HashCode=7262386)'.
BindingExpression:Path=RoundingFactor;..........
This doesn't appear to be an exception, but we are concerned it has a performance impact.
Should we be concerned and create a view model that has all the properties we wish to bind to (and have the properties that dont exist on the underlying element return null) or can we just leave it.
This situation often occurs in a grid scenario where there might be large numbers of these binding failures.
I haven't tested this myself but a blog post from the Visual Studio team says that binding errors indeed impact performance:
WPF tries several different ways to resolve path errors, including searching for attached properties and this is quite expensive.
You're only seeing that output because you're running inside Visual Studio. Normally those trace statements go nowhere because there is no trace listener. Either way, the performance implications are completely negligible.
Exceptions, on the other hand, would be a very costly way of reporting binding failures, particularly because - as you note - there are often bindings that work against some objects but not others.