All,
I have finished the GUI design phase... Now I've started to add meaningful names to all the controls in my application. Visual Studio is driving me nuts auto generating the events each time I click on the control to change its name (ok so it only happens when I mess up and double click... but still annoying).
Is there a way to temporarily disable this feature? I still want it because it is a great short cut when I'm coding.
Thanks!
You can't disable double clicking AFAIK but you can open document outline (Menu View > Other Windows > Document Outline), and rename the controls via F2 in this window. It'll be much faster and will help see easily the visual tree if your form is complex.
afaik there is not. Just be careful with your clicking and if you do mess up CTRL+Z CTRL+Z is your friend :)
If you can recognize which controls are which in code, you could open the .Designer.cs files and rename the controls there with the refactoring tool (right click the control name, Refactor, Rename).
It may or may not be straightforward to recognize which controls are which given that you have used generic names so far, but at least it's an option. Personally, I avoid that situation by immediately assigning meaningful names.
It's not just renaming controls, it's resizing them by dragging that is a bigger problem. CTRL+Z works to remove the auto-generated code but simultaneously undoes the resizing of the control. Very annoying.
Related
I'm making a WinForms program for my Diploma final project using C# and Visual Studio.
Sometimes I accidentally double-click a tool and that opens up the main event for the tool, like button_Click. But when I delete that code and check the Designer, it gives me an error message. If I choose to ignore it, all of the Form's formatting is lost and I have to start over (real pain in the a**).
I usually just click the - to minimise the code block and then add comments that the code is unused. But as you can guess, this makes for a really ugly and unorganised coding page.
Is there any way for me to remove the code and not get a Designer error?
Go to the Form.Designer.cs file or F12 on the InitializeComponent() method.
Then on the right margin look for the red dots and delete the events pointed to methods that have been deleted.
Anyone got a quicker way?
When opening a Form in the Visual Studio Designer, the generated designer files' contents get mixed up randomly. This includes the files
Form.Designer.cs and
Form.resx
When using a version control system this is a real nightmare.
Is there a way (extension?) that sorts and cleans up all designer files before saving? This would solve most of my VCS related issues with WinForms, as it reverses all the shuffling the designer does.
This problem sure does make merging difficult - I understand your pain.
Read this previous SO post:
"Why does C# designer-generated code (like Form1.designer.cs) play havoc with Subversion?"
Basically you could create a tool to sort all the code alphabetically to give order to the random placement of code, but it is a hack and could involve a lot of pain itself. Personally I recommend changing your work practices to reduce this occurring.
Reduce time between merges
Limit access to a form to 1 developer at a time.
Merge under the guidance of the developer who made the change, as they will know better what looks ok.
Don't open the designer, if you are only making a "code change", ie nothing changes visually.
Undo changes to the designer file before merges, if you are 100% sure that you didn't change anything.
This is not a tip about automatically sorting Form.Designer.cs; however, it does help with avoiding merge help with all modifications made to Form.Designer.cs-files by Visual Studio.
Instead of (or in addition to) changing your work practices (by Jonathon Lee) and especially the constricting "Limit access to a form to 1 developer at a time" do:
Ensure the Form.Designer.cs-file is organized according to Visual Studio in a separate commit before you make the real changes.
Trigger a reorganization of the Form.Designer.cs-file by Visual Studio
(For me, moving a control from one cell in a TableLayoutPanel to an other and back again did the trick.)
Commit Visual Studio's changes and mark them as nothing changed.
Make your modifications to the Form
Trigger a reorganization of the Form.Designer.cs-file by Visual Studio
Commit your changes and describing your work.
Results:
This helps reviewers to distinguish changes to review from noise.
This eases merging:
either, your version control system detects that two commits have the same effect and one is enough and it can merge without conflicts;
or, you manually resolve the conflict by applying just one of the cleanup commits and discard the other.
Right now for my User Controls I right click the control in the Solution Explorer and then choose 'View Code'. Then, in the top right corner where all the class's elements are enumerated in a dropdown box, I choose the grey'd out constructor and this brings me to the auto generated .designer.cs file that I'm looking for.
I feel like this is a really round-about way of doing it and it doesn't sit well with me. Am I supposed to be doing a better job of avoiding editing these files? Are they hard to get to on purpose or did I just clearly miss something simple in Visual Studio?
You should quite simply be able to use the treeview of the Solution Explorer to expand the user control items and see the code-behind and designer files.
This is curious, so I wonder what kind of user control (any particular project type)?
As for avoidance of editing these auto-generated files: yes, you should be weary in doing so, and avoid it wherever possible. Your changes are going to disappear if the code is ever regenerated (not that likely for user controls, I suppose), and the developers of the tool that generated it can't vouch for it working as it should if edited.
There are times when you do want to edit these kinds of files, however. So use your own judgement to evaluate the value of doing so. I find myself dipping into the DBML designer files often enough to delete the default constructor which conflicts with my own in the partial definition, haven't found another way to do what I want. Such is the situation.
Editing autogenerated code is never a good idea. The reason being that the code can be generated at any time and your changes will be lost. If you really, REALLY need to edit the code, you should be doing so using partial classes. But 95% of the time you shouldn't need to edit autogenerated code in the first place. What exactly is it that you're trying to accomplish?
An easy way to do it: Let's say you have a Label control called Label1.
If it is never actually used in your code, place some code that uses it somewhere in one of your methods:
private void Test() {
Label1.Text = null;
}
Now, put your Cursor over the Label1 control and press F12. This will take you to the definition of Label1
Hope that helps!
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.
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.