Evacuate Event Handlers

When you need create a brand new web form, Visual Studio.NET offers a template that has everything wired up and ready to go. As you add server controls and hook up click/change/etc events, it's kind enough to write event hooks for you. Unfortunately, due to some annoying bugs it also takes liberty to wipe out event handlers while you're not looking.

A basic web form template has the following code region in it:

#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
 //
 // CODEGEN: This call is required by the ASP.NET Web Form Designer.
 //
 InitializeComponent();
 base.OnInit(e);
}

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{    
 this.btnTest.Click += new System.EventHandler(this.btnTest_Click);
 this.Load += new System.EventHandler(this.Page_Load);
}
#endregion

You see at least two warnings that you shouldn't delete or modify anything. The sample page I show here has a button with its Click event handler.

I love it that Visual Studio.NET creates an event handler for you, but I also hate that it may choose to remove it if I reshuffle controls on a page. For example, if you remove a control from the page, its event handler should go as well. But...

The other day VS.NET purged my Page.Load event and left me wondering why that page wasn't processing anything. Looking for a missing this.Load line was the last thing on my list.

I hope this is fixed in VS.NET 2005, but for the time being I choose to remove those threatening comments and reclaim control! I tend to move event hooks into OnInit like this:

#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
 InitializeComponent();
 base.OnInit(e);

 this.btnTest.Click += new System.EventHandler(this.btnTest_Click);
 this.Load += new System.EventHandler(this.Page_Load);
}

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{    
}
#endregion

At least VS.NET never messes with OnInit. This event is fired very early in the page life cycle which makes it an excellent place to initialize things.

There's one downside to it: if you remove controls you're going to have to remove their event handlers by hand, but I regard this as a small price to pay for peace of mind.

I feel your pain. I've had that disappearing page load event handler happen before. Took me hours to work out why my form suddenly stopped working. Moving those lines seems a bit drastic. Might as well eliminate using the designer altogether.

I've decided to give ReSharper a try. It's pretty "intelligent" when it comes to event handlers. It can create most of the code for me, so I haven't been using the designer at all lately.

This kind of problem doesn't happen always only by moving or removing controls in a page, the question is what is the cause of the problem? I am having such a hard time fighting with the Designer now and then. Anyone with justification, please?

the solution provided is good. but there is a problem with it. if there are lots of controls in that page and to find out the code for suppose the click event for a button, what we usually do is double click on that button from .aspx page design view. but at that time an event handler is created automatically for that button click and it will be placed inside the initializecomponent() function. so the same delegate will be there in twice and during execution , it will be executed twice creating more problems

Yep, you are right Sajitha Jose. Nonetheless, extending the workaround by removing the handler first then adding the one you want should guard against code being executed twice.

I am a vb guy so I would first run...
RemoveHandler btnTest.Click, AddressOf btnTest_Click
in c# it might be something like...
btnTest.Click -= btnTest_Click;
then add it again here. Slightly ugly but if you go this route then this would solve it.