why is a page_load significant in aspx.cs? - asp.net

Can someone explain to me the sheer purpose of a page load? My code runs just fine without it right now in my aspx.cs (codebehind) file. I am doing very basic stuff here, so im guessing it has a lot of importance somewhere so i am just wondering what that would be. thanks for any help!

You should check about the Page Life Cycle.
The load is an event in this Cycle.
About the method, Page_load() is the method on the server side application, for an .aspx file. All code inside of this method is executed once at the beginning of the page.
Also, in the load, if the current request is a postback, control properties are loaded with information recovered from view state and control state. (Different from initialize, when you set the default values)
So, in the Load Event, the Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page.
Some links for you:
ASP .NET Page Life Cycle
Page_Load and Postback
and there are a few more in Google

Related

why my user control in asp.net web application fails to load after each postback & loads for first time only

i am using user control in asp.net , it is loading for first time in page load event & later on every post back event it doesn't load at all.
Note. I am adding user control in page_load event in if(!ispostback) condition.
Is there a way to avoid reloading user control every time??
Thanks.
Sorry: You must create dynamically created controls EACH and every time the Page loads, if you "avoid" it there just is no control. PostBack or not, everything you want to use must be created.
Also, please create controls in Page_Init, it belongs there, especially if you're relying on PostBack and ViewState.
Further reading: ASP.NET Page Life Cycle Overview

Pitfalls of using LoadControl in the Load event

I use LoadControl method in Load event quite extensively. However I haven’t observed any problems yet, I’m afraid of what MSDN documentation says:
When you load a control into a container control, the container
raises all of the added control's events until it has caught up to the
current event. However, the added control does not catch up with
postback data processing. For an added control to participate in
postback data processing, including validation, the control must be
added in the Init event rather than in the Load event.
What does it actually mean?
Are there any other pitfalls when loading a control in the Load event?
That bit of MSDN documentation is (mostly) wrong. As you've discovered, postback data processing and validation work even if you dynamically add controls in the Load event.
Here are the stages of the ASP.NET page life cycle that are relevant to this question:
Raise the Init event.
Postbacks: Load view state and control state.
Postbacks: Load posted form data (first attempt).
Raise the Load event.
Postbacks: Load posted form data (second attempt).
Postbacks: Validate the form and raise the postback event.
The documentation is correct when it says that "the added control does not catch up with postback data processing". But it overlooks the fact that there are two attempts to load posted form data, once before the Load event and once after. Thus, if you dynamically add a control in the Load event, it will be populated with posted form data by the time the postback event (such as submitButton_Click) occurs.
As far as I can tell, here's the main difference and potential pitfall:
If you dynamically add a control in Init, you can access its posted form data in Load.
If you dynamically add a control in Load, you have to wait until the postback event (or else access the HttpRequest.Form collection directly).
It means that by the time Control_Load executes, the postback cycle has come and gone. If you have a control that needs to participate in postback, you need to load it before, so that's why the docs recommend doing it in the Init override instead.
If your controls don't participate in postback then you're OK.

What could be the reason to hit page_load more than once

When I click the Button I am loading one page. i am having some controls in the page_load.
but the problem is my page_load is hitting more than once.
Please can any body explain me what could be the possible reasons for hitting the page_load multiple times.
Thanks
Is hitting Page_Load twice your issue?
Most probably its due to asp:Image or img without src defined.
To quote mbanavige of ASP.NET Forums,
if you have an img tag with an empty/missing src attribute, then the
browser may re-request the current page (or may request the default
page) why trying to satisfy the empty src for that img tag.
Another possibility that occurs from time to time is that the
page_load event has been wired up twice.
Related: page loads twice in Google chrome
This is by design. In the page life-cycle it is called on the initial request and on the postback.
http://msdn.microsoft.com/en-us/library/ms178472.aspx
ASP.NET webforms are self-posting, so Page_Load will hit hit everytime a time a post back occurs. If you would like to only execute certain code on initial page load, add the following to your Load event handler:
if (!Page.IsPostback)
{
// Code here
}
This says only execute this code if this is the first request to this page.

ASP.NET: Viewstate and programmatically adding user controls

When programmatically adding user controls using LoadControl(string path), when, in the user control's page life cycle, does it initialize its sub-controls with its viewstate?
I'm asking this question because one of my user controls that's being programmatically loaded has a TextBox control that is not being initialized/loaded by it's viewstate on PostBack on the Page_Load event (which is not the case for a regular .aspx pages and hence my confusion). Overall, I need to retrieve values from the Textbox control.
Thanks
ViewState is loaded before the Page_Load event. If you want your control to work with ViewState, you need to load it and add it to the page before that event — usually on PreInit.
The life cycle reference is here:
http://msdn.microsoft.com/en-us/library/ms178472.aspx?ppud=4
Read the description for the Pre Load event, which immediately precedes Page Load:
Use this event if you need to perform processing on your page or control before the Load event.
Before the Page instance raises this event, it loads view state for itself and all controls, and then processes any postback data included with the Request instance.
Thus by Pre Load time it's already too late. Also, the description for the PreInit event specifically mentions that it's the place to "create or re-create dynamic controls."

ASP.Net: User controls added to placeholder dynamically cannot retrieve values

I am adding some user controls dynamically to a PlaceHolder server control. My user control consists of some labels and some textbox controls.
When I submit the form and try to view the contents of the textboxes (within each user control) on the server, they are empty.
When the postback completes, the textboxes have the data that I entered prior to postback. This tells me that the text in the boxes are being retained through ViewState. I just don't know why I can't find them when I'm debugging.
Can someone please tell me why I would not be seeing the data the user entered on the server?
Thanks for any help.
This is based on .NET v1 event sequence, but it should give you the idea:
Initialize (Init event)
Begin Tracking View State (checks if postback)
Load View State (if postback)
Load Postback Data (if postback)
Load (Load event)
Raise Changed Events (if postback)
Raise Postback Events (if postback)
PreRender (PreRender event)
Save View State
Render
Unload (Unload event)
Dispose
As you can see, the loading of ViewState data back to the controls happen before the Load event. So in order for your dynamically-added controls to "retain" those values, they have to be present for the ASP.NET page to reload the values in the first place. You would have to re-create those controls at the Init stage, before Load View State occurs.
I figured out yesterday that you can actually make your app work like normal by loading the control tree right after the loadviewstateevent is fired. if you override the loadviewstate event, call mybase.loadviewstate and then put your own code to regenerate the controls right after it, the values for those controls will be available on page load. In one of my apps I use a viewstate field to hold the ID or the array info that can be used to recreate those controls.
Protected Overrides Sub LoadViewState(ByVal savedState As Object)
MyBase.LoadViewState(savedState)
If IsPostBack Then
CreateMyControls()
End If
End Sub
I believe you'll need to add the UserControl to the PlaceHolder during the Init phase of the page life cycle, in order to get the ViewState to be filled in by the Load phase to read those values. Is this the order in which you're loading those?
Ensure you are defining your dynamic controls at the class level and adding them to the ASP container:
Private dynControl As ASP.MyNamespace_MyControl_ascx
And when you instantiate the control, ensure you call LoadControl so the object is added properly:
dynControl = CType(LoadControl("~/MyNamespace/MyControl/MyControl.ascx"), ASP.MyNamespace_MyControl_ascx)
You have to create your controls in the Page_PreInit event handler. The ASP.NET server control model is tricky; you have to fully understand the page lifecycle to do it right.
As others have said, any form of control manipulation must be done before viewstate is created.
Here is a good link on the page lifecycle to help you out:
http://msdn.microsoft.com/en-us/library/ms178472.aspx
We have experienced the same thing and have handled it by using ghost controls on page_load that have the exact same .ID and then the post back picks up the events and the data. As others said it's the dynamic adding of the control after the init stages that the state is built already and controls added after aren't stored.
Hope this helps a bit.
I also want to add that I've seen user controls work the way that you'd expect them to just by setting the Control.ID property at run time. If you do not set the ID, items may get built in a different order and work oddly.

Resources