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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With