We have a complicated legacy form built in Winforms that recently has started seriously misbehaving and it gets worse and worse as time goes on. Just opening the form in design view will alter the layout of the form, sometimes in minor ways (a control is resized to be a pixel smaller) and sometimes in major ways (a component is moved to X position -6582). Due to the size of this form and the nature of the generated .Designer.cs referring to the diff is almost usually useless to determine whether the changes that were made to the form were the changes that you actually intended.
Based off a number of suggestions I found in other questions:
visual studio 2005 designer moves controls and resizes Form
Visual Studio keeps resizing my form without me telling it to, help!
Controls moving in vs2008 design mode on build
AutoScaleMode is set to None. I experimented briefly with various monitor resolutions, to no avail. Ultimately we decided to stop relying on anchors and instead use a combination of TableLayoutPanels and Dock properties. And that's when the trouble really started...
After heavily redesigning one of the hairier tabs on this form, when I tried to save Visual Studio spun for 2-3 minutes and reported "Could not load file or assmbly 'MyProject, Verion=X.X.X.X, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" (as seen here: Visual Studio 2013 Can't save, build, or rebuild solution). This happened whenever the form attempted to save. After following the advice in the accepted answer, I was able to save/build again.
Attempting to run not much later resulted in a very, very long build time and a completely empty form (as seen here: All controls on a form are invisible and https://stackoverflow.com/a/5524183/1015495 ). All calls to Controls.Add had been removed from the designer (I assume this massive change is what resulted in the long build time). I restored the form to a previous version and began recreating my changes. Now, much more insidiously, certain controls have had all of their children removed.
Working within this form is becoming a timesink at best and unfeasible at worst. The solutions that I've found online basically boil down to "recreate the form manually" or "don't use Winforms". Unfortunately neither of these are an option right now. How can we mitigate the problems that we're having with this form in the mid-term future until we can come up with a proper fix?
I am working through an almost identical problem at the moment and mine seems to be a bug in Visual Studio 2013 related to having a "linkLabel" control on a User Control, which is on one of the tabs of a tab control on the main form.
I had other linkLabel controls on the parent form that did not cause any issues. The weird thing is that not ALL of the tabs were messed up, only some of them. I can only conclude that it gets through part of the layout restructuring, hits the user control, and bombs out, failing to finish the layout correctly. I attached a second version of visual studio to try to catch exceptions, and saw various status lines showing up in the debugger, but did not see any exceptions thrown. I am not that familiar with doing that, so it's possible I did that wrong though.
I could revert the code back to after I had added the user controls, but before VisualStudio opened the form in the designer and automatically re-generated the designer code. At this point, opening the form in the designer will always cause exactly the same design failures. As long as I never opened the code in the designer again, everything would work correctly at run time.
If I removed any reference to the custom user controls with link labels, the designer would also open without any trouble. At first I assumed I had an error in my own code so I started commenting things out, but it was still happening even with just the basic elements dragged on. So then I started removing elements and adding them back one at a time to see what broke it. In my case this turned out to be the "linkLabel" control. I am not sure if there are other controls that will do this yet. For now I just plan on re-writing the code to not use a link label on the user control though and see how well that goes.
Related
I am having a rather odd issue that I have been unable to find the answer to. I have 2 PCs that I am doing coding on - one a desktop PC and one a notebook (QuadHD resolution). Each has Windows 8.1 & Visual Studio 2013 Update 5 installed.
I have localized all my Forms and it seems that when I edit the Winform on my notebook, it causes very odd resizing issues to occur. For example, if I simply change the "Language" property from one language to another (that I have already translated), the entire form is skewed and re-sized, completely destroying all the layout of the form in the selected language. On another form, the "ImageScaling" property is erroneously changed from 16x16 to 40x40.
The issue seems to be related to the changing of the 'Language' property. Almost like there's some sort of resizing logic & layout logic being applied when this property is changed.
When I perform the same operation on my desktop PC, I get no such odd modifications (as I'd expect). This obviously renders my notebook completely useless for being able to do any WinForms work!
I initially thought this might be related to some quirk with the QuadHD display (i.e. 3.2k x 1.8k). I have tried to reduce the screen resolution to a regular HD quality, however this doesn't seem to resolve the issue.
Does anyone have any hints about what I could try to fix this problem?
Thanks.
The only workaround I have been able to come across so far is to ensure that your Windows Settings->Display->Scaling is 100% BEFORE making any modifications to the form (including changing any seemingly innocuous properties such as 'Language').
On high-resolution screens, this unfortunately makes the content almost unreadable but at least the forms are not completely ruined/resized when you edit them.
You will unfortunately need to do all your edits in this mode and commit them before reverting your scaling back to its original setting.
I've currently got custom control that has somehow lost its parent and is now not parented to anything but it's still in the list of controls in the form designer. The delete button also doesn't work and is thus disabled. This happens every now and again and its a pain to go through the designer code and remove manually, plus there are other developers that this will annoy and may confuse them.
I'm therefore trying to add a Verb within the controls ComponentDesigner to delete itself from the form. But I realised that because its not 'childed' to anything, it therefore cant be removed as a child. How would I therefore go about deleting a control from the form designer via code?
This can happen when one of your controls throws an exception at design time. That's rarely a silent event, the designer shows a popup message box. Not getting a message box may happen when you swallow exceptions in your code with a try/catch.
Trying to fix this by hacking a designer just adds to the problem. Fix it by editing the designer code, it is okay when you know what you're doing. If you can't find the reason then get it to a point where you can make it somewhat reproducible. Then start another instance of Visual Studio, Tools + Attach to Process and select the first instance. Debug + Exceptions, tick the Thrown box for CLR exceptions so the debugger will stop when the exception is thrown.
Back up the file.
Open up the designer file; e.g., Form1.Designer.cs
Expand this region: Windows Form Designer generated code
You should be able to find your control in the code and delete it. Be careful.
I solved the issue by finding the loose controls within the Document Outline tab. This way is super easy and is graphical.
Does the visual studio IDE have an issue with eating up the contents of a winform made with custom controls? I have a few and haven't had a problem, but I made a form recently that was nearly 80% out of custom controls (those being made up usually of normal windform controls themselves).
I didn't have much of a problem making them, up until about yesterday when VS lost reference to what it was doing and I spent a day figuring it out. I had to delete about 3 controls and reposition them from the designer manually to get it to stop. It then affected one of my major forms, instead of stopping like I had thought I had fixed it. Seems it lost all calls to my custom controls, and after a few hours I did a clean solution/rebuild solution. A few controls were missing again, reassigned them and it was work.
About an hour later my project stopped saving, stating it couldn't find the project's position. I closed the IDE and reopened it, all my coding changes were saved and up to do, but every single custom control in my form was deleted. Repositioning them isn't going to be more then an hour or two, but is this a common issue for VS2010 and a good argument to go with another IDE, or is this just bad and random luck? Anyone have any experience with something like this?
I have a winforms application that I am writing in C# - in Visual Studio 2010. I have one specific form that keeps corrupting itself every other day or so - according to TFS, it looks like most of the file is re-written by the designer when I have made only the smallest changes. (location of buttions, etc.) Things fall off strips, toolbars, etc. as well as errors just trying to use the designer. See my other post Here. (Thought I figured this out, but I guess not)
Here is an example piece of code that goes missing - when I put it back in, it takes it back out when I save the file. The code was generated by the designer in a previous file version.
this.statusStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.tssEmployeeName,
this.tssLoadTime,
this.tssSpring,
this.tssHomeLocation,
this.tssTotal,
this.tssDue});
Is there any way of 're-generating' the [file].Designer.cs file? Or should I bite the bullet and re-do this form? (pain with over 100 components on this one...) It's the only form I have a problem with out of the 35 or so in the project.
VS 2010 w\ SP1.
Thanks, Andrew
I've experienced this before, although I'm not sure if my issues were exactly the same.
Try putting a handful of problem controls, such as your StatusStrip control and its children, into separate User Controls. Then add those User Controls to the main form instead. At the very least, you can prevent the designer from rewriting those controls.
With small projects, I can switch to design view almost instantly (< 1 sec).
I have a large project that takes about 60 seconds to open a control or form in design view - for the first time only. After this 60 second delay, I can open any control in the project in design view almost instantly - until I recompile the project.
If the exe built by this project is referenced in another (small) project, the small project instantly becomes as sluggish as the large project. Similarly, if I add all the files from the large project to the small project individually, the small project becomes as sluggish.
The large project references a large Managed C++ project, but if I add the same reference (and call a function from the reference to make sure it is loaded) to the small project, the small project is still fast.
My large project uses SandDock. If my small project uses SandDock, it's still fast.
My large project has about 60 user controls that appear in the toolbox. If I add 60 user controls to the small project, the small project is still fast.
If I make the user controls hidden from the toolbox with [System.ComponentModel.ToolboxItem(false)], the large project is still slow.
The problem occurs in both vs2005 and vs2008.
What could be making the large project so slow to open design view for the first time? Some other reference? The large number of controls? The large number of classes? Some other cause?
One thing I've noticed (though possibly a red herring) is that the ProjectAssemblies folder (C:\Documents and Settings\tim.gradwell\Local Settings\Application Data\Microsoft\VisualStudio\9.0\ProjectAssemblies) is huge (> 1GB) and most of the folders in here have a copy of my Managed C++ dll! These folders appear to get recreated every time the design view is re-opened (after a recompile). Could this have anything to do with the slowdown?
Further Info:
A toolstrip in the user control or form makes the form take 60 seconds to load. Removing the toolstrip (but still having several other different controls on the form) makes the switch to design view instant.
That's not the whole story though... A toolstrip in a brand new project doesn't cause massive slowdown - so there must be something in my big project which is affecting toolstrips. Also, certain other forms/controls that don't have toolstrips on them are still taking 60 secs to display the design view, so whatever it is that is affecting toolstrips is also affecting other controls too. I'll keep trying to nail down precisely which controls and maybe even what it is that's causing it!
Even though you have marked the classes to not appear in the Toolbox, Visual Studio still needs to scan all of your open projects to discover that. To speed things up, you need to turn off the setting to automatically populate the Toolbox. It can get a bit annoying if you do lots of work with the toolbox, but it will speed up things a lot.
The setting is in Tools -> Options -> Windows Forms Designer, set "AutoToolboxPopulate" to false.
The first answer: "The setting is in Tools -> Options -> Windows Forms Designer, set "AutoToolboxPopulate" to false" worked for me. The designer used to hang for at least a minute when trying to get focus on a control on a form when first looking at a form in design view. Now, it takes only a few seconds. (I didn't have enough reputation points to directly comment on that answer)
The same similar thing is happening with my 2005 in additon to that the devenv.exe hangs randomly
and even after "building" sometimes the custom controls tend to corrupt the main form
have you recently virus scanned and defragged?
I had this problem on a Win CE 6.0 project in Visual Studio 2005. The project uses System.Data.SQLite.dll v1.0.65.0. Each time I opened or recompiled the project, and then tried to open a form with a grid for design, there would be at least a 12-minute delay. Turns out it was generating 770-odd folders under "My Documents\Local Settings\Application Data\Microsoft\Visual Studio\8.0\Project Assemblies", most of which had a copy of just the SQLite dll.
The issue appears to be that I had referenced this DLL in the project from a "sibling" folder to my project. As an example:
Project folder: "...Projects\ThisAndThat\projectFolder"
DLL folder: "...Projects\ThisAndThat\projectFolderBin"
There may be other folder relationships that manifest this problem, but I did not investigate.
I moved the DLL into the "Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE" folder and the problem went away. I have a form with a tab control containing two tabs. Each tab contains a datagrid control. This form now loads almost instantly in the designer.
If anyone knows of a better solution, or what setting or behavior of VS2005 causes this issue, please add a comment.