When I attach a event on a control in my Windows Form I've got the problem that, after a few time, it detaches from it automatically. Let me explain, For example if I've got this line of code:
this.btnMainMove.MouseMove += btnMainMove_MouseMove;
And then I'll write the method btnMainMove_MouseMove in the form code, it works well for a few times but then in the designer file the line written above automatically deletes and I remain only with the method in the form code file.
This thing doesn't happen for the Click event but only for the methods that I create like MouseMove, MoseOver, KeyDown.
I'd like to know why this happens and how I could prevent this.
Thank you all!
Designer files are generally well marked with a message like so:
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.18034
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
The message is pretty clear. Changes can and will be lost.
These kinds of files, for instance, often have a tool that can be executed manually (using context menu options) but are most often executed automatically, after saving the accompanying *.cs files, compiling, etc.
Attach your events in the constructor, on load, or using the visual designer (which will track requirements based on layout files and other such things, but out of your concern).
I don't know what's the problem but i can suggest you use lambda expressions and not the designer
this.btnMainMove.MouseMove += (sender,event) =>
{
//your event logic here
};
but do this without clicking the event in the GUI of Visual Studio so you don't use the designer.
Are you editing *.designer.cs file manualy?
It is good to avoid it, but you can subscribe to this event in constructor, right after InitializeComponent() method.
The designer makes changes only in *.Designer.cs files...
If you add the Handlers in the Constructor or the Load-Event of the form the designer won't delete your code.
Related
I am getting this error when i open the design of a Winform.
Message 1244 The designer cannot process the code at line 108:
this.cancelButton.DialogResult = DialogResult.Cancel;
The code within the method 'InitializeComponent' is generated by the designer and should not be manually modified. Please remove any changes and try opening the designer again.
But when either i remove this piece of code from the designer.cs or change it to
this.cancelButton.DialogResult = System.windows.Forms.DialogResult.Cancel;
it works. My problem is i have this problem at almost all the winforms over a solution at many places. How can i resolve this issue to all places? Any way?
Advice from #zespri and #bansi are some good pieces, but you are suggested to do all customized construct time design in your constructor, after InitializeComponent().
I'm working on cleaning up an app I'm almost finished with and I noticed something that made me curious as to why it's being done that way. While you can edit the .Designer.cs in your project for a form, there is a lot of autogenerated stuff in there, such as the creation of variables and controls. They have the Windows Form Designer generated code which hardly ever gets touched by me. But as I was making variables in the format I like them:
string strValue1,
strValue2;
As compared to:
string strValue1;
string strValue2;
I noticed that Windows declares the controls on the bottom of the file then creates/instantiates them in the InitializeComponent() function. Now, I knowI could take the "new" instances and put them where the declarations are and it seems to run fine. My question is what's the benefit of one over the other? Or is this the way it is so Windows can autogenerate them for us? If there's a possibility of better performance for doing it one way over another, I'd like to know. Thanks guys for the help.
Example 1:
private void InitializeComponent()
{
...
this.control1 = new System.Windows.Forms.Control();
...
}
...
System.Windows.Forms.Control control1;
Example 2:
private void InitializeComponent()
{
...
}
...
System.Windows.Forms.Control control1 = new System.Windows.Forms.Control();
Do not edit that code. It is auto-generated and the designer actually reads the code back to recreate the form in the designer. When you make changes like this, it is very likely you'll bomb the designer and your form becomes un-designable. Even if you do manage to avoid crashing it, your changes will simply disappear when you alter the form in the designer.
Anything in the region that's marked "Windows Forms Designer generated code" is hands-off.
There is no benefit whatsoever to changes like these. It generates the exact same code.
You can get some more control over stuff when its done in the InitializeComponent
If you open up your .cs file (not the designer) and look at the constructor
public Form1()
{
InitializeComponent();
}
this way you can have code execute before the controls are instantiated..
if you would just create the controls when they are declared then you would not be able to do this...
I wrote a bunch of code in the .cs file in c# for a winforms application. The application runs fine, and everything is in it's place.
Something like this:
using..
namespace Temp
{
public class Temp : Form
{
Button b1;
TextBox t1;
Temp()
{
b1.Text = "Some Text";
b1.Size = new Size(50,20);
...
}
void function1()
{
// stuff
}
static void Main()
{
Application.Run(new Temp());
}
}
}
How can I modify my code (or fix it somehow) so that the design view displays the elements in their correct positions and view so that I can visually edit them instead of having to trial/error everything.
Edit for Clarification
My application runs fine. The problem is, that I didn't use designer to create the application and so in the designer view, the app is empty. But not empty when I run it, since everything is positioned programmatically in the .cs file. My question is, how can I fix this, so that the designer shows the objects correctly.
There is no quick fix other than to redesign everything?
So to get this shown within the designer you have to know how the designer works.
For every MyForm.cs there will automatically be a file called MyForm.Designer.cs be created. Within this Designer file there will be only one function called InitializeComponents(). This function will be called within the constructor of your MyForm.cs file.
The design viewer itself is responsible for the Designer file, so any change to this file while the design view is open would normally be discarded. Also if you put some code into the designer file that is not needed be the designer will be truncated.
So the next question is, when will this truncation happen? When you freshly open the design viewer of a form, it will read in everything from the Designer.cs file without making any changes. If you make any changes onto the form by the designer the complete file will be rewritten with all the settings already read in including your latest changes.
This behaviour can be monitored if you open the designer file also as source code view, make some little changes in design mode and afterwards take a close look at the left of the source file. There will be the changes marked with a yellow or a green marker.
Now after all this stuff of informations, you can try the following procedure to get your code into the designer:
Open the design view and put some simple control onto your form (e.g. TextBox)
Save and close the design view and open the Designer.cs file as source file
Copy all your variables name of your controls at the end of the file, right below the textBox1 line
Copy all your control property settings within the InitializeComponent() function right below the property settings of the TextBox
Copy all your control constructors to the top of the file, right below the constructor of the TextBox
Save the file and open your form in design view
Select the dummy TextBox on the design view and delete it
This change within the DesignView leads to a complete rewrite of the designer.cs file, ordering all your manually added stuff the right way.
So this is the way to go. Last but not least another little trick:
Every programmer uses the using-statement to not write the whole path to every class (like System.Windows.Forms.TextBox), but the designer writes always the whole path. To make it a little easier for your copy and paste session you can also add a using statement at the top of the file. After saving and changing something in Design View all this stuff will be re-written automatically. So you don't need to add all this paths manually while your adding your stuff to the Designer.cs file.
Your best option is probably to use the properties panel in the designer to set the positions etc (or maybe just drag them?).
You could go digging around in the designer file for the form (something.Designer.cs), but this isn't a fantastic idea because it can be pretty sensitive to changing things in ways the designer doesn't expect. Having said that, it looks like you're not actually using the designer to make your form (the class would be partial, for one thing), in which case you're SOL.
In that case, you need to copy the designer code from CS to designer.cs. So that you can use designer. I think this is the simplest approach.
Looks like this file was hacked from a class file instead of being generated by the system when you create a new winform.
You need at least an InitializeComponent(); call in your constructor. However you are missing a lot of other code that is generated for you when you create the file such as Dispose().
Best bet would be to right click your project in the solution explorer and click Add Windows Form then start over.
I'm new to the Visual C# designer so these are general and pretty basic question on how to work with the designer.
When we for instance add a label to a form and then double-click on it in the Visual C# designer (I'm using Microsoft Visual C# 2008 Express Edition), the following things happen:
The designer generates code within Form1.Designer.cs (assume default names for simplicity) to add the label,
then with the double-click it will add the event handler label1_Click to the label within Form1.Designer.cs, using the following code
this.label1.Click += new System.EventHandler(this.label1_Click);
and it adds the event handler method to Form1.cs
private void label1_Click(object sender, EventArgs e)
{
}
If I now remove the label only the code within Form1.Designer.cs will be removed but the label1_Click method will stay within Form1.cs even if it isn't used by anything else. But if I'm using reset within Properties->Events for the Click-event from within the designer even the label1_Click method in Form1.cs will be removed.
1.) Isn't that a little inconsistent behavior?
2.) What is the recommended way of removing such generated event handler-code?
3.) What is the best "mental approach"/best practice for using the designer?
I would approach it by mental separation in the way that Form1.cs is 100% my responsibility and that on the other hand I'm not touching the code in Form1.Designer.cs at all. Does that make sense or not? Since sometimes the designer removes sth. from Form1.cs I'm not sure about this.
1) Yes, it is inconsistent. A little.
2) I used MUCH MORE SIMPLE approach: simple wipe out all your handle code and try to compile => compiler will show you where to wipe out an event assignment. Despite of scary look, it is really safe.
3) Here is my best practices which I recommend and kind of enforce in my software department:
3a) Switch to WPF (ask for best WPF practices separately; there are a lot of other problems);
3b) NEVER ever allow Visual Studio to auto-generate event code (WPF or Windows.Forms); in case of accident use (2) as soon as possible;
3b) For event assignment use anonymous lambda:
ByButton.Click += (source, evArg) => { SomeHandler(...); };
for v.2.0:
ByButton.Click += delegate(object source, EventArgs evArgs) { SomeHandler(...); };
There are many benefits: your handlers are not bound to using specific method profile; you can put whole code inside anonymous handler is it is short enough, in lambda form you may never need to know the type of Event Arguments...
There probably is a element of safety built into Visual Studio.
For example:
Add a button A and a click event.
Reference the button A click event from another button B.
Remove button A
if the code were to go then button B would break
if the code remains then button B continues to work.
I generally comment out any code (event handlers) that break in the designer.cs file.
I was just curious how others work with this kind of WinForm code in C#.
Lets say I have a Form lets call it Form1. And I have a DataGridView called dgvMain.
Where do you put the code:
this.dgvMain.CellEndEdit += new DataGridViewCellEventHandler(dgvMain_CellEndEdit);
Do you put it in the Form1 code or the Form1 designer code?
Should this "event wiring" code go in the Form1_Load method?
The reason I am ask is... if you double click the DataGridView the IDE inserts the code:
this.dgvMain.CellContentClick += new System.Windows.Forms.DataGridViewCellEventHandler(this.dgvMain_CellContentClick);
into the designer code. Should your "event wiring" code be in two places?
Short answer is yes.
Longer answer is that .designer.cs is there for code generated by the designer. if you put your own code in there, it has a chance of getting overwritten, screwing up the design time stuff in visual studio, and lowers maintainability because nobody expects custom code to be in there.
This is a touchy subject. In 1.1, there where regions for this in your forms file, but a lot of the time, the code would be over written by the designer. I'm speaking from webforms experiance, but I would only gather that it would be the same elsewhere.
Now, you actually put the eventname in the form itself (it's one of the properties on the forms designer), and the code generator will push out the += event handler thingies in the partial class. I hate it this way, but it is what it is.
I use the Designer for all event related to Component.
I use the code for all object event.