Attention: We have retired the ASP.NET Community Blogs. Learn more >

New LoadFinished event for Page

Note: this entry has moved.

Lots of people starting to learn ASP.NET tend to heavily depend on the Load event. They find quite naturally to write most core logic into Load until they realize their code just doesn’t work as expected and start coding all kind of hacks.

 

A common example of this mistake is to write code in Load that depends on values that will be updated only after postback data has been processed; but as Load fires before postback data (2nd try) and RaiseChangedEvents and RaisePostBackEvent are processed such code won’t work properly -- and that is when people start writing hacks like peeking at the Forms collection to get the updated value; the WebForm model is not followed and bad things happen when you do that J

 

If you still doesn’t get the scenario I’m talking about take a look at this post.

 

The solution to this? Move your code to PreRender, sure; but this doesn’t sound very intuitive to a beginner.

 

I believe that adding a brand new event to Page, something like LoadFinished that fires right after 2nd try postback data and changed & postback events are processed and right before PreRender would be a more natural choice where to put such code.

 

You could then market this new event as the one that fires when the page has completely finished its loading and the place where any code can safely depend on all postback data to be updated.

 

 

7 Comments

  • shouldn't code relying on a postback (f.e. a button is clicked) be placed in a routine that is fired from the eventhandler of that button f.e.?

  • Frans yes but the Page load event is still executed whatever the Event you link to the button.


    I use intensively now Prerender event, but the event cycle can be quite complex when you have all your controls with their own events.

  • Hi Frans,





    Not always. The code that goes into an eventhandler is just for handling that specific event and won't run on every postback (ie. if the button wasn't clicked). So you still need a place where to put "general" code that must always run and depend on the updated values (ie. PreRender).

  • Yep, we've added an event for this purpose - LoadComplete.





    We've also added various other events in the page lifecycle that should be useful to page and control developers.


  • this is testing


  • Move To PreRender..... :-S



    Isn't it better to check in PreRender if the Property changed and then call EnsureChildControls or soemthing?

  • As an ASP.NET 1.1 solution, what I do is, in the Base Page that other aspx pages derive from, I override the RaisePostBackEvent() method and raise a custom event. This way, even UserControls on the Page can wire handlers to the event to respond at the appropriate time. Your thoughts?

    protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument)
    {
    base.RaisePostBackEvent (sourceControl, eventArgument);
    this.OnPostBackEventsComplete(new EventArgs());
    }

Comments have been disabled for this content.