6

Let's say we have a pretty standard form with a textbox and a button (for simplicity). You want to handle a Click event and do some stuff based on user's input.

I was wondering, does it matter, when exactly you wire up an event handler for the Click event in a code-behind? If it does, where is the best place to put it? Page load? Page init? I've tried both places, but didn't notice any difference. Or it's just a personal preference of the programmer? I've already searched the internet couple of times, but haven't found any satisfactory answer.

I know when the actual method execute, just not sure about the wiring-up part.

walther
  • 13,466
  • 5
  • 41
  • 67

2 Answers2

15

As you know, there are several Page_xxx event handlers, like Init, Load, Prerender... This events exist in Controls, and Pages as well as User controls (in fact they're derived form Control, which holds all these events).

This events are related to the ASP.NET Page Life Cycle

If you read the page pointed to by this link carefully you will understand when the events are triggered. So, if you bind your event handler in any page lifecycle event that happens before the events are triggered, it's guaranteed that your event handlers will be bound in time to be triggered.

These are the main lifecycle steps:

PreInit -> Init -> InitComplete -> PreLoad -> Load -> [Control events] ->
LoadComplete -> PreRender -> SaveStateComplete -> Render -> Unload

Not all of them have associated events, but, if it's necessary you can override the corresponding OnXxx() function, like OnPreInit(). (This is usually only done on custom server controls).

You can bind events in Page_Init or Page_Load, because the control events are triggerd after the loading of all the controls has finished. The Load step happens in top-bottom way, first in the Page, and then recursively in all the children controls.

After Load finishes, the first events which are triggered are the Change Events, like TextChanged or SelectionChanged. Then are triggered all the other events, like Click.

If you bound the events in PreRender or Unload, they wouldn't be triggered. If you did in Init or Load, they would.

So it could look like it's safe to bind in Init or Load, but that's not true:

It could look like there's no special reason to bind them on Init or Load, because they'll be triggered later in the page life cycle. But, as the binding defined in the .aspx happens during Init, a programmer will expect that all events are already bound in the Load event. What would happen if this programmer raised an event of a child control in code behind? The Load event happens first in the root of the control tree, and them on all of the children, recursively. So, by the time the programmer is trying to raise the event of the child control, it won't be already bound. So this won't work as expected. This is more than enough to consider unsafe to bind events in Load event. That's why you should always bind events in Init.

Look at this diagram to see the order of execution of Page & children events: ASP.NET Page Life Cycle Diagram

JotaBe
  • 38,030
  • 8
  • 98
  • 117
  • That's the exactly the reason why I've posted my question. I'd like to have a deeper understanding on WHY and WHEN to do certain things. I think I understand the page lifecycle, when to create my controls etc, but wasn't sure about this wiring-up thing, because I've seen different approaches. While some programmers do it during Load event, others like Init. So to complete my question - do I understand it correctly, that it doesn't really matter that much and I just need to be sure not to do it after the Load event has finished? (LoadComplete, Prerender etc.) – walther Apr 18 '12 at 00:15
  • I think this answers your question thoroughly now, after the edit. – JotaBe Apr 18 '12 at 01:01
  • Yes, finally got a satisfactory answer to my question, thank you :) – walther Apr 18 '12 at 07:22
0

I have been wiring mine up in the control tag. If I do it this way it is clear that an event handler is present.

<asp:Button ID="btnRefresh" runat="server" Text="Refresh" OnClick="btnRefresh_Click" />

If I had to wire up an event handler in the codebehind, I would put it in Page_Load as a private function call.

DaveB
  • 9,470
  • 4
  • 39
  • 66
  • Yes, I know of this possibility, but... I'm not really a fan of this, because I like to separate my layers as much as I possibly can. I have a coder who works on the presentation layer (javascript, html, css..) and I really don't see a reason why should he know or even care about wiring up handlers. If I'm working alone, it might perfectly fine, but this doesn't really answer my question. Where would you wire up a handler, if you HAD to do it in a code-behind? – walther Apr 18 '12 at 00:09
  • @walther - Thanks for the comment. I understand the need to keep things separate. If I had to put it in the codebehind, I would first create a function to setup my event handlers and then call the function from Page_Load. – DaveB Apr 18 '12 at 01:31