We Keep Coding

Events automatically detaching

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.

Efficient Declaration/Creation of variables/controls

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...

Visual C# GUI Designer - Recommended way of removing generated event handler-code

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.

Visual Studio web user control events only show up in design mode?

Calling all Visual Studio gurus — when I'm working on a .ascx or .aspx file in a c# web project, the events do not show up in the properties panel unless I switch into the design view from the code view. Is this an intentional functionality of Visual Studio? Both VS2005 and VS2008 seem to work this way.
And is there any way to get the events to show up in the properties panel all the time?

I don't know if that's the way VS is 'intended to work, but yes that's a limitation. In case you've noticed sometimes clicking on the control and pressing F4 (or clicking on the properties tab) fails to load the properties for the correct control, and then you gotta select it from the list.
Sigh
That apart, if you make a usercontrol of your own, and give it an event, that event will not show up in the properties tab when you put it on a page. You'll have to capture it manually in the Page_Init event (like demonstrated by fallen888).
These days I don't bother with going to the properties tab to see an event. You can just as well type the event's name in the mark-up and then write it in the code-behind file.

Yes, that's how Visual Studio is intended to work. This doesn't help you view them in properties panel, but you can get a list of events (among other things) by typing the following in the code-behind:
"this." and intellisense should show you a list.
What I typically do is override the OnInit method and put all event handler mappings in there. So that it looks something like this:
override protected void OnInit(EventArgs e)
{
this.Load += new System.EventHandler(this.Page_Load);
this.myButton.Click += new System.EventHandler(this.myButton_Click);
base.OnInit(e);
}
If you do it using intellisense, as soon you type in "+= " you'll have the option to auto-complete that line and the event handler method's signature as well.

Yep, I wish we had a similar level of event autocompletion that we get with WPF where you can see the event name in IntelliSense and get it to automatically create a new stub event for you in code behind :(

ASP.NET UserControl's and DefaultEvent

Outline
OK, I have Google'd this and already expecting a big fat NO!! But I thought I should ask since I know sometimes there can be the odd little gem of knowledge lurking around in peoples heads ^_^
I am working my way through some excercises in a book for study, and this particular exercise is User Controls. I have cobbled together a control and would like to set the DefaultEvent for it (having done this for previous controls) so when I double-click it, the default event created is whatever I specify it to be.
NOTE: This is a standard User Control (.ascx), NOT a custom rendered control.
Current Code
Here is the class & event definition:
[System.ComponentModel.DefaultEvent("OKClicked")]
public partial class AddressBox : System.Web.UI.UserControl
{
public event EventHandler OKClicked;
Current Result
Now, when I double click the the control when it is on a ASPX page, the following is created:
protected void AddressBox1_Load(object sender, EventArgs e)
{
}
Not quite what I was expecting! So, my question:
Is it possible to define a DefaultEvent for a UserControl? Is it a hack? If it's [not] supported, is there a reason?
Side Note: How do we put underscores in code? I cant seem to put and escape char in?

Here is a possible answer, without testing (like martin did).
In reflector, you will see that the DefaultEventAttribute allows itself to be inherited.
In reflector, you see that the UserControl class has it's default event set to the Load event.
So the possible reason is that even though you are decorating your user control with the default event of OKClick, VS might still be thinking that the default event is load, as it's being inherited from UserControl whose default event is Load.
Just a high level guess at what might be happening.

OK, I checked this out, Inheriting from WebControl rather than UserControl.. All worked fine.
Looks like Darren Kopp takes the crown for this one! Thanks for the input!