Bear with me, this is possibly a very specific problem we've encountered here:
We have a silverlight application that gets its data from a WCF (not RIA) back end service. We are displaying a collection of addresses in a dataform for the program user to edit, add to, or remove addresses from the collection.
The Addresses are bound to the Dataform as an observable collection, and the AddressView class (partial class via WCF), has been extended to implement the IEditiableObject interface.
The problem we are having is that the add/remove buttons are disabled on the control. The kicker is that this was working previously, but seems to have stopped at some point while squashing bugs and refactoring, and we haven't been able locate any related code changes.
Looking into the actual code of the dataform, the add/remove buttons are always disabled because the control attempts to cast it's internal collection to an IEditiableCollectionView, which fails, and I'm not sure why.
Any leads or pointers to try is greatly appreciated.
Found the issue to the problem. The assembly version for System.Windows.Data was incorrectly pointing to the SL 3 version. When this was changed to the SL4 version, everything began to work properly again. There's a lesson in this: when in doubt, check your references!
Related
My application is working fine, all of a sudden while loading a designer in wpf form, im getting errors.
Object reference not set to instance of an object.
As if it is in a loop. After pressing the enter button for sometime. Im getting this error.
Microsoft Visual Studio XAML UI Designer has stopped working.
And after this, im getting this.
System.Runtime.Remoting.RemotingException
[9980] Designer process terminated unexpectedly!
The number in square brackets is changing evrytime.
Im using Visual Studio 2012. Im not yet running the application, Im just switching to designer mode from code behind. If I compile and run the application, it runs fine.
Kindly help.
Edit:
Here are the three errors in single image. (I cant post morethan one link)
xamlerrors
There's an error either in the code-behind or DataContext (if you're using a ViewModel). After you fix that error, click on Click here to reload the designer. What's happening is that the designer is trying to load everything up during design time and since there's an error, it's unable to, as if the program was actually running. That null reference exception can be a bit misleading in terms of trying to figure out the cause, because it'll be thrown if you have an error in your code-behind or ViewModel.
Things to check:
Is your View referencing the correct ViewModel?
Is your code-behind portion of the View matching the View name? Some people copy their Views, but forget to change the Class name in the code-behind.
Do you have any errors in your ViewModel?
What about models? If they're loaded during design time and contain errors, this could cause the above exception.
I noticed that those kind of errors are almost everytime caused by
an error in the parameterless constructor of the view
an error in the constructor of the view model which is attached to the view
Keep in mind that when the designer loads, it calls the parameterless constructor of the view (there has to be one for the designer!). If there are "complex things" done there which can only performed correctly at runtime, there will likely be errors at design time.
The same is true for the constructor of the view model which is called from the view.
Check whether design mode is active
For example you should not load data from a repository in a constructor.
If you do it in the constructor, at least check whether the design mode is active or not like explained in this answer here about the GetIsInDesignMode attached property and only do the complex logic in the constructor if the design mode is not active.
Debugging the problem
You also have the possiblity to debug the problem. In order to do this, you have to open a second instance of Visual Studio and debug the designer process of your original Visual Studio instance from there.
The process is described in detail here: Debugging an Exception (only) occurring in design view
I've been working on a SL5 app for a few days. I've mostly been using a hard coded dummy data collection when styling my app's view. Everything has been working fine, but now I want to connect it to a dynamic data collection generated by my view model (using the data service technique where you have design time & real data depending on the IsInDesignTool property.
After I cleared out the control of the hard coded data and bound it to a collection in my view model. When I run it in debug mode, I see an unhandled exception being thrown in App.xaml.cs. The exception args don't say exactly what the problem is (it is simply saying "Value does not fall within the expected range" but when I look at the sender I find the following coming from the MainWindow (my app only has a single view): "Out-of-browser specific settings do not affect in-browser applications."
Further, when I try to view the MainWindow in the designer in VS, it doesn't render and instead shows an error (the rendered exception in the designer doesn't have any of my namespaces in it, just things about controls & UIElements).
I'm at a bit of a loss how to troubleshoot this. I didn't set anything for out-of-browser when building the app and since it worked with dummy data collections, why would it suddenly have this issue (seems like if I was using an out-of-browser property it would have shown up before I bound the data to the view).
Tips/pointers?
(sorry for my bad english)
I am not sure on what is happening but I saw the error "Out-of-browser specific..." when I tried to access some specific property only available to OOB while running on browser. The solution was to test if running oob before using the property:
if (Application.Current.IsRunningOutOfBrowser)
{
Application.Current.MainWindow.WindowState = WindowState.Maximized;
}
The other problem possibly is unrelated - and sometimes can be really hard to debug - one thing that helped me is to open another instance of VS and attach it to the one where you are seeing the problem. With this setup, go to your problematic View and change to "design view" - keep an eye on the Output window of the attached VS to see if some meaningful exception is shown.
I had a similar issue.
I did put a Textbox inside kind of Listbox (radPanelBar) and added
HorizontalScrollBarVisibility="Auto" to the Textbox. It seems that the textbox had problems when to show the scrollbar and when not. Adding
ScrollViewer.HorizontalScrollBarVisibility="Disabled" to the Listbox did solve it ( so, no OOB issue at all ).
I'm not entirely sure what the error was, but it wasn't at all realted to OOB. I'm using a data service approach (in design time I programatically build real data, not the Expression Blend sample data, but when not in a design tool, it uses the REST services). I started disabling a lot of things in my dynamic data and slowly added them back. Somewhere along the way my dummy data generation was fouling things up, but SL thought it was an OOB issue.
I have a C#.NET winforms project, and some controls are moving in design view whenever I build the project. Its only some of the controls (a panel with a label and datagridview in it, a button, a link button and a label) are all moving up on each build.
Has anyone seen this before or know how to fix it?
I think it is because of the AutoScaleDimensions. My guess is that your form was originally created on another machine.
Per MSDN.
"The AutoScaleDimensions property represents the DPI or font setting
of the screen that the control was scaled to or designed for.
Specifically, at design time this property will be set by the Windows
Forms designer to the value your monitor is currently using. Then,
when the form loads at run time, if the CurrentAutoScaleDimensions
property is different from the AutoScaleDimensions, the
PerformAutoScale method will be called to perform scaling of the
control and all of its children. Afterwards, AutoScaleDimensions will
be updated to reflect the new scaling size."
My guess is that for odd some reason when you build you project property (maybe some others) gets adjusted, but not on design time.
I think about few possible reasons:
You work on multiple monitors and/or there is some odd stuff with your adapter.
There is some problem with auto-generated designer file. Maybe it
edited manually somehow.
To fix I propose to do something I would do:
Recreate form from scratch if possible, by copy-pasting bits
one-by-one.
If not take some merging tool and insert fresh form
properties.
Also here is another interesting question on AutoScaleDimentions.
We are using DevExpress Silverlight PivotGrid (11.2.7). The problem is that none of the popups work as one would expect.
Here is the xaml code (note that all of these properties are True by default and don't need to be set)
<dxpg:PivotGridControl
x:Name="pivotGrid"
... data bindings ...
IsFieldValuePopupMenuEnabled="True"
IsHeaderMenuEnabled="True"
IsHeaderAreaMenuEnabled="True"
/>
Once the host control for the grid is shown and the data is loaded right-clicking on any of the relevant areas doesn't bring either of the popups (there are 3).
Strangely (or not so strangely) in the sample SL project provided by devex everything works as it should.
The one (significant) difference between the sample app and our project is that we are using MEF and relevant .xaps are loaded dynamically based on which user logged in and some other stuff.
We have tried a lot stuff to figure out what is wrong but haven't managed to find anything even remotely relevant. Here is what we have tried :
Adding the pivotgrid to the host tabpage in codebehind after imports have been satisfied;
Setting / resetting properties mentioned above after imports from codebehind;
Adding the control to the startup page of the project before the MEF madness kicks in;
We also tried to popup the menus manually by inheriting from the pivotgrid control, but that has not yielded much;
Enabled RedrawRegions to make sure the popup is not popping 'under'. It's not;
Any pointers or ideas would be greatly appreciated.
Regards,
Alex
It appears that this was some bug in the version we were using at the time.
After updating to 12.1 everything works like it should without any tinkering from our side.
Looks like devex guys have bugs too...who knew right :)
I've created a series of usercontrols. Dragged one of the controls to the main form. It shows OK. Went back and made a change to the design of the user control. Rebuilt project. Cleaned project. manually removed all project binaries including the obj folder. Change still doesn't show on the usercontrol hosted on the main form. Dragging a new instance of the control from the tool box only shows the old version of the control.
Completely removed the controls from the toolbox and adding them again fixed the problem, but surely I don't have to do this everytime I make a change? All user controls are in the same assembly as the main form. Tool>Options>Windows Forms Designer>Auto toolbox Populate is set to true. Any ideas most appreciated. Thx
Do not add the control to the toolbox yourself. This puts a copy of the assembly in a private directory. Yes, this copy does not get updated automatically, you get the old control.
Rely on the "Auto toolbox populate" setting. It automatically adds any controls you have in your loaded project(s) to the toolbox. The added controls are at the top of the toolbox.
I agree with answer 1 that that is what is supposed to happen, and often does. But it doesn't always work and will work partially sometimes.
For example my current Solution.
Project 1 namespace ToolsTester - This is just a temporary form to test the view tools in the 2nd project.
Project 2 namespace UltimateFileFinder - This has three views.
The first 2 views (user controls) UltFilesView and UltSlideShow appeared as usual on the toolbar so I could drag them onto ToolsTester to try them out.
Then I added another user control UltPanel, this will not go onto the toolbox. Though it compiles without errors.
I have come across this problem a few times, sometimes removing and reasserting the reference fixes it. Other times I would have to remove the test project and create a new one.
I tested Visual Studio (full version) before release and this was one of the areas I reported back, so the problem was known pre-release.
This project I am on now I know that I will need to remove the test project and create a new one, in this case the tester is only a few simple caller and event responses, that is not always the case, there are times when the tester project can be quite complex because it is mimicing the target that the tools will be part of.