Start a new Silverlight application... and in the code behind (in the "Loaded" event), put this code:
// This will *NOT* cause an error.
this.LayoutRoot.DataContext = new string[5];
But...
// This *WILL* cause an error!
this.LayoutRoot.DataContext = this;
The error that is raised is "Value does not fall within the expected range." BTW, this code works 100% in regular WPF (Windows development), and there should be no reason why it won't work in WPF/E :)
Any thoughts?
You can't currently use visual elements as a data source for data binding in Silverlight 2. I think this is slated to be added for Silverlight v.Next.
You can use visual elements as data source if you create binding directly in the code, but trying to assign visual element to DataContext will throw ArgumentException. It doesn't make much sense, but silverlight is just on version 2.
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...
I'm encountering a problem with the WinForm designer. I made a new UserControl, I added a DataGridView, some other elements and a TreeView. With the gui I named all those new components. Now it's time to code that stuff and I realise that the designer missnamed my node of my TreeView. The Designer also added new columns from my DataSource even if it was set to AutoGenerateColumn to false. I though: "Well time to clean some Designer crap again..." and I cleaned that stuff up in the InitializeComponent function (I know it's labeled "Do not modify with the code editor" but... do I have the choise?
Anyway, my problem is : When I go back on the Design view, the VS Designer seems to regenerate the code back but not even how it was. Now the designer declares my DataGridView and my TreeView as local members of InitializeComponent function. I can easily repair and undo my changes but I would like to understand and know if there is a way to disable the auto code generation of the designer.
Also, I tried to make another function which have all what I need so the designer don't screw it up and call it into the initialize component. This solution works at run time but not on Design view. I'm kinda low.
As far as I know, the short answer is no. If something is marked as Do not edit due to code generation., then do not edit it :). I would suggest reading up on partial classes, as that is how you can modify classes without actually messing with the auto generated code. In your case, you will need to go into the designer and fix everything there so that the auto generation works as you expect it to.
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!
I've created a custom control (a class that inherits from Control). When I put it on a Form I can work with it on Visual Studio IDE. It shows me an error and I don't see the form.
The error message is this: La variable 'ctrlImagen' no está declarada o no se asignó nunca.
It's a winform for a Compact Framework app.
How can I solve this? (it the class inherits from UserControl it works perfectly)
Sounds crazy, but Visual Studio is selectively executing code for your control in the designer. First thing to check is your constructors. Make sure you have an empty, default constructor, that is public, even if you never plan on using it. After that make sure any code you have tied to layout events (such as resize) are good to go, these are likely the culprits, as thats where I always find problems when my custom controls don't work in the designer.
It sounds like you have a bug in the code for your Control. This sounds like a runtime error that is preventing the control from rendering.
Re-read your code and look for potential null-pointer exceptions, unassigned variables, stack overflows, etc. The bug is lying in their somewhere.
Any chance your user control doesn't have a public default constructor? I can get a similar error "The variable 'userControlX' is either undeclared or was never assigned' if the constructor isn't public.
Would need more info, though.
It seems a design time exception has happened in initialization logic that gets executed before your form initialization logic executed. A good example would be a NullPointerException fired by the default constructor (or one or more methods it invokes) of a user control that contained by your form.
I put this on constructor to solve the problem:
this.ClientSize = new Size(21, 21);
The beging of my class is this:
public class ControlMapa : Control
{
public ControlMapa()
{
this.ClientSize = new Size(21, 21);
...
Thank you!