I haven't done much work with .NET, so forgive me if this has a trivial solution.
The "problem" (more of an annoyance, really) is that the VC# IDE opens all files that have a class which inherits from System.Windows.Forms.Form in design-view, by default. The only exception being "*.Designer.cs" files.
Generally speaking, this is fine. However, if I have a partial class that implements some control handler code, this becomes quite an annoyance. When double-clicking on the source file, for instance, you are taken to the Winforms designer and presented with an empty form. Totally useless.
To get around this, you are required to right-click on the source file in question, and select "View Code" from the context menu.
My question is rather simple: is there any frigging way to get around this absurdity?
If not, I'm wondering how people organize their UI-handling code.
Thanks!
Yes.
In the file's context menu, select "Open With..." and use the "Set as Default" button with your prefered editor selected (in your case, probably the CSharp Editor).
Rather than right-click and view-code, I always use Doubleclick and it goes to the code page, focussed on the Form_load event, which can be left blank and ignored.
If you really want to fix the behavior, I suggest somehow making your file not be a Form! Cant blame VS for thinking you want to work with a form when you open a form's file!
Single click the file in the Solution Explorer and press F-7.
Related
I am a beginner to Visual Studio 2015 and C# and am looking for some general advice I could not not find anywhere else, so please bear with me.
Let's say I create a new Windows Forms Application, in the Solution Explorer I can already see Form1.cs has been added to the tree, and child to this is Form1.Designer.cs and Form1.
Now I want to add another form by right clicking WindowsFormApplication1 and Add > New Item...
The Solution Explorer now looks something like this:
For my first C# project I am recreating Notepad which should not be overly difficult, this will allow me to familiarize myself with the language and syntax etc.
I have added a second form to my project which will be the Go To line number form, shown from the Edit menu in Notepad.
Suppose I want to give Form1 and Form2 more meaningful names what is the correct way to do this?
From the properties inspector I named Form1 as frmMain and Form2 as frmGoTo but I noticed in the Solution Explorer the parent names are still Form1.cs and Form2.cs:
So I right clicked each parent node and renamed them too like so:
My question now is was this the right or wrong approach? I feel like I am going to have naming conflicts maybe.
To test I tried showing the frmGoTo form like so:
Form frmGoTo = new frmGoTo();
frmGoTo.ShowDialog();
I think I did this right, the frmGoTo does show correctly but as I say I have my doubts regarding the way I renamed the forms from both the property inspector and Solution Explorer.
Was there anything wrong with what I did above, should I have used separate naming conventions for the property inspector form name and the solution explorer name etc? Will I run into any problems naming the forms like I did above?
I suppose I am looking for some clarity as to how best to rename forms within a solution?
What you did was not wrong, but there is an easier solution build into Visual Studio solution explorer. Right click on item and select rename:
Visual Studio will then ask if you want it to perform project-wide rename for the classname of the form:
By answering yes, everything should be in order.
I imagine this question has been asked and answered, but I cannot find it.
I wanted to make a simple GUI to interface to a windows 7 command. I usually use Wx, but since this was to be a windows-only thing, I decided to see if I could whip it out real fast using Visual C# 2010 Express, which I had never used before.
Things started off just great. I created a form, put a few buttons and text boxes and such on it, and hit Debug. It came up and ran just like that. No muss, no fuss. So I then designed the form just the way I wanted it, renamed the controls from "Button1" and so forth to meaningful names. But now it's a mess. By clicking around, I discovered that VC# had auto-generated two files called Form1.cs and Form1.Designer.cs. The later contains the bindings between functions and the events generated from user-clicks etc., and the former contains no-op code for those functions, for me to complete.
Problem is, the names are all still the original "Button1" and so forth, not the new ones, and the new controls I added after running the first time do not appear at all.
I want it to regenerate all that stuff afresh from the finished form. How to?
You probably don't have an actual problem, unless you edited something within Form1.Designer.cs. Provided you left that file alone, things should just work.
Whenever you double-click on a button, or use the events interface to create event handlers, the handlers are created with the following pattern:
ObjectName_EventName()
So, for example:
Button1_Click()
If you later change the name of Button1, the event handler's name is not changed, too. But it is still attached to the proper event, again - assuming you did not edit anything in Form1.Designer.cs
If you look (but don't touch!) inside Form1.Designer.cs, you will probably find something similar to:
MyNewButtonName.Click += Button1_Click;
(I don't recall the exact syntax the editor uses for wiring up event handlers; the principle is you should see your new button name being attached to the old handler name)
i want to ask abt Sharpdevelop.
Can i change the control's event name in sharpdevelop ? I want to add "_" like in visual studio.
For Example, button click event in Sharp develop defaulted to Button1Click. can i change to Button1_Click like in visualstudio ?
Thanks.
Mike Webb's answer is the only way to generate an event handler method name with an underscore without modifying SharpDevelop's source code.
Lex Li's answer is also correct. There is no option in SharpDevelop to enable automatic generation of event handler method names that use an underscore. The only way currently is to modify the source code. It is a fairly straightforward code change.
Download the source for SharpDevelop.
Extract the code.
Locate the EventBindingService class (src\AddIns\DisplayBindings\FormsDesigner\Project\Src\Services\EventBindingService.cs)
Locate the CreateUniqueMethodName method.
Modify the single line of code in this method to use an underscore in the string format:
return String.Format("{0}_{1}", Char.ToUpper(component.Site.Name[0]) + component.Site.Name.Substring(1), e.DisplayName);
Build SharpDevelop from source code by running src\DebugBuild.bat or src\ReleaseBuild.bat
Then when you use your customised version of SharpDevelop and double click a button in the forms designer, for example, you will get an event handler with a name like "Button1_Click".
At some point in the future SharpDevelop 4 will allow this with an option that can be selected in Tools - Options.
Yes. If you go into design and look in the properties window for the control you will see a few icons at the top. One of these should give you the list of events (in VS it is a lightning bolt). In the left hand column are the linkable events and in the right hand column are the functions that are called when the events are triggered.
Simply rename the left hand field and make sure you have the function named correctly in code as well. You can also type a name into the left hand field and then double click inside it to generate the function automatically.
The underscore is evil to some people, like me :)
Well, if you do want the underscore, check out SharpDevelop source code and locate that part and modify it. It is open source, so you can do whatever you like to please yourself. I did not see a setting available somewhere, so modify the source code seems to be the only way to achieve your goal.
I know this is an old thread but in SharpDevelop v4.3 (v4.x - v5.x) there is a solution to this. In the past i've had to use the above method, however this one is much faster and easier.
Launch SharpDevelop and check the following setting:
Tools > Options > Windows Forms Designer > General > "Generate Visual Studio Style Event Handlers"
Working with VS.NET 2008, output type Class Library, Target Framework .NET 2.0
I've come up with a simplified scenario to ask this question.
I have a Button user control, its a simple panel with a single big button on it.
I want to create a RedButton control that extends Button, and similarly, a GreenButton.e.g. Class RedButton : Button
Ideally, when I open up RedButton's designer I will see the button that I created in Button and be able to modify it, for example make it Red, or change font, etc.
I've tried to do this once, but when I open up the RedButton's designer I just get a bunch of errors.
In this case, doing all this work programatically isn't an option for us, as in the real case this would be a pain.
Could someone shed some light on this?
Thanks Very Much.
Truthfully, your example should work just fine. Just ensure that you provide a default constructor for your derived class. Also ensure that you do not use generic controls as the designer will have no clue how to create an instance of it.
Is your assembly setup to be delay signed? Look for the delay signing attribute as well as the checkbox in project properties. I've seen delay signing cause this sort of problem with VS2005 perhaps its still a problem in VS2008.
I had to deal with this problem for years at an old company. I researched it a little back then. I don't think that there is a solution for this.
I don't know how much you want to extend the base class in your real example, but the changes you mentioned in your example would be trivial. Just something like
btnTheButton.BackGround=Color.Red;
In reality, probably whatever changes you need to make to button could be done in a few minutes. It is unfortunate that this will be a few minutes everytime you need to inherit a new control, but I think it's the only option
If the control you inherit from is from a DLL and not just another class in the solution, then your designer will render the inherited control properly. My guess is that the VS Design View needs the DLL to draw the control. There may be other ways around this as well.
Since VS.NET 2008 the root designer is able to present "bunch of errors" as you mentioned. In general the described scenario should “just work”.
What kind of errors are you facing?
Follow this example if you aren't already:
public class RedButton : Button
then in the XAML instead of
<UserControl></UserControl>
Start/end your XAML file with
<Button></Button>
Note that it is okay to inherit from something in another namespace even though you didn't define the namespace yet. Example:
<radDock:RadPane ...
xmlns:radDock="clr-namespace:Telerik.Windows.Controls;assembly=Telerik.Windows.Controls.Docking"
...
Title="{Binding Path=StudyTitle}"...
My workshop has recently switched to Subversion from SourceSafe, freeing us from automatic locks. This led to concurrent editing of the Forms, which is wonderful. But when multiple developers commit their changes, the code files created by the designer (all the files named TheFormName.designer.cs) cause conflicts which are very difficult to resolve.
As far as I can tell, this is because the code generated by the designer is heavily re-arranged whenever the user modifies it, no matter how little the actual change really did.
How do I make these conflicts easier to resolve?
Is there some way to tell the designer to modify the code less?
How do you, the experienced C# teams, deal with concurrent modification of a Form?
Here are some things to try:
Make things more modular. Use components like User Controls etc. to split forms into multiple, smaller physical files.
Use presentation layer design patterns like MVP to move code out of views and into standard POCO classes.
Recent versions of SVN allow you to take hard locks - use this to avoid complex merge scenarios.
Hope that helps.
I'm pretty sure there is no silver bullet for this problem as the designer stomps all over the designer.cs.
All I can suggest is to minimise the use of the designer. Personally I only hook to events in code and only use the designer only for initialisation and positioning. As such it isn't too hard to fathom differences in a changeset ("oh, someone has added a button", "oh, someone has changed how it looks slightly").
Yep, Designer's random rearranging sure is irritating. Does Microsoft use their own tools? Does Microsoft look at what they check into version-control? It boggles the mind.
Our team's "solution" is to hand-edit the Designer files after we're done editing them, to put things back to where they were, so that the text-based diff is readable, and so concurrent changes can be merged sanely. Luckily, most of Visual Studio's rearranging is simple-minded, so this works.
Sadly, we've found that this step is necessary to verify correctness -- we've found cases where Designer silently removes things that are needed, leading to broken code. So this step has to be done in order to work around whatever data-destroying bugs lurk inside. Sigh.
Since Microsoft has a poor track record of fixing its bugs, the only solution may be to improve Mono's WinForms Designer so that it's ready for prime time.
I'm not familiar with C# or the Windows Form Designer, but looking at some designer.cs files I could find online they don't have a particularly complicated structure.
What parts of it are being re-arranged? I guess it's mostly the order of the properties in the InitializeComponent() method that's jumbled up?
If that's the case, you might be able to write a simple script that re-orders those lines alphabetically, say (especially if you never edit these files manually anyway), and use that as a pre-commit hook script in Subversion.
Um, right... scratch that. The big red box at the bottom of that section says you're not supposed to modify transactions in hook scripts. But you might be able to find another way to run that script somewhere between the designer.cs file being changed and it being committed.
Edit:
Actually, given scraimer's comment on this:
Total hack, but in the worst case, just before a merge, I could sort BOTH files, and make the merge simply a line-by-line affair...
Can't you let Subversion set an external merge program? I've been using KDiff3, which can run a preprocessor command before doing diffs or merges, so you could automate that process.
It's true that the designer sometimes messes up the order of the controls in the code, which causes the file to look very different compared to a previous version. This indeed is a problem if the file is under version control.
However, I found that the designer works quite reliably even in very large forms and user-controls if you follow some rules, and in those rare case where it does not, I have a easy way to force the designer into arranging the controls in the "correct" order again.
My rules:
The comment at the top of InitializeComponent() in every .designer.cs says: do not modify the contents of this method with the code editor. Well, if you know what you're doing, then it's absolutely no problem to edit this file manually, because this is what you need to do. Just make sure you have a backup.
Typically, when you create a form or UC, you add some controls here and there and move them around until you find a nice arrangement. But in the .designer.cs file, the controls are ordered by the order of their creation, and not by your logic how they belong together.
After finishing the creation of the form or UC, I reorder both the declarations (at the bottom of the file) and instantiations of the controls and their adding to the respective parent control (both in InitializeComponent()) until they are in the order that I want them to have. This makes it much easier to find them if you have to change a property of a control in the code.
And it also makes it easier for version control, because you may easily see what part of your form or UC was changed just by seeing the place (rather towards top or bottom of the file?) of the change in a file comparison view.
But changing the order in these 2 sections does not automatically change the order of all the parametrization code that comes after the instantiation part in InitializeComponent(). This will be done when you execute the solution to the OP's problem, which is described next.
If you work with rule #2, then you need to do the same finishing work that you need to do when you encounter the problem that the OP describes:
You have to force the designer to arrange controls in the order that they have in the declaration and instantiation.
This can be done in a quite simple way (which worked for me in 99% of the cases so far):
Save all files of the form or UC
open the designer view
move one of the controls (e.g. by selecting it and hitting 1x left arrow key)
optional: look at the .designer.cs file and/or save the form or UC
move the control back to have your intended design (e.g. by hitting 1x right arrow key)
save the form or UC
The designer will rewrite the whole .designer.cs file and your controls should now be in the "correct" order.
There are rare cases where this does not help. These include DataGridViewRows in embedded DataGridViews and embedded UserControls. In these cases I additionally do similar finishing work which includes adding and removing a button:
Save all files of the form or UC
open the designer view
add a button anywhere in the form or UC
optional: look at the .designer.cs file and/or save the form or UC
remove this button again
save the form or UC
The only way I know of to truely avoid this problem when using a merge style source control system such as subversion is to hand code the forms and not use the designer. Obviously, this would not be good because hand coding these forms can take a while.
The reason this happens is because the control properties are serialized by the designer in the order they are dropped on the form. Cutting and pasting can effect this order as well as moving a control so that it has a new parent (such as moving a control on to a panel when it was previously directly on the form).
I had this problem on a large project and had to imploy a rather ugly approach - diff the designer.cs files against the check-in target revision and manually merge them using a merge tool. This isn't ideal, but it is the only way I see this working consistently with svn or another merge style source control tool.
The other option would be to use a lock approach with source control, as others have pointed out, but this comes with unpleasant side effects as well.