Question

When creating a new WebForm, Visual Studios creates a Page_Load handler in the code behind as a default, which is cool. So for years, I have always put code for doing things like set properties of controls in Page_Load. Recently, I used Reflector to look at some assemblies written by Microsoft and saw that they have put the same type of logic in a method called OnLoad (which supposedly raises the load event). So I started to wonder, where is the best place really to set the properties of controls, in OnLoad or Page_Load? Or in a different method altogether? And if not Page_Load, why does Studio add that to the code behind?

My final thought: Although I know that putting logic in OnLoad works fine, I will probably stick with Page_Load for now because that's conventional. I asked the question really to find out if I had been missing out on something new after I started seeing OnLoad come up in other people's code. Thank you all for your thoughtful answers!

Was it helpful?

Solution

Page_Load is just the autoeventwireup for OnLoad. You would think that it doesn't make any difference which is used, but I agree with K. Scott Allen at Ode to Code that you should usually only deviate from the norm when you are trying to do something unexpected. Overriding a virtual method like OnLoad suggests that you are trying to do something different such as not calling base.Onload, which most programmers are typically not.

OTHER TIPS

You don't want to use OnLoad, the reason they use that is because it's a wrapper for raising the Page_Load event. They put logic in there because they're not handling the Page_Load event.

In short, continue using Page_Load.

Typically, OnX methods are methods that raise the event X. They are kind of like the class' internal event handlers. That means, when you code a class which, among other things, detects a certain event occuring, you'd typically call a method that: 1. does what your class needs to do in that case, 2. fires up the external event.

I believe one of the core reasons why this has caught on was that, as it stands, you can't just call the event delegate to fire an event, you have to always check if said delegate is null. So you want to encapsulate this check in a method.

In short, unless you're writing your own class that has a Load event, you don't need to think of an OnLoad method.

All very valid points so far. But don't let these guys scare you. You won't hurt anything if you want to use the OnLoad method. Just don't forget to call base.OnLoad().

Indeed, if you go back to the bad old days of ASP.Net 1.1 development, you actually see the wiring up taking place, created for you in each and every page:

    #region Web Form Designer generated code
    override protected void OnInit(EventArgs e)
    {
        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.Load += new System.EventHandler(this.Page_Load);
    }
    #endregion

And every now and then, I'd do something that caused VS to remove that little line in the InitializeComponent, and couldn't work out why my page stopped doing anything.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top