Can i Consider the responsibility of InitComplete event as follows
1) It is the last stage of page initialization
2) If ViewState is enabled at page level it will calls Page.TrackViewState() method inorder to make the view state to be ready for persisted across postback.
Thanks
Babu
According to MSDN
Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event.
Use this event to make changes to view state that you want to make sure are persisted after the next postback.
1) It is the last stage of page initialization
Yep
2) If ViewState is enabled at page level it will calls Page.TrackViewState() method inorder to make the view state to be ready for persisted across postback.
Nope, by the time you get to InitComplete, ViewState tracking has already been turned on. As the last section of the documentation states, purpose of the even is to changes to the ViewState.
Related
Can anyone please tell me the order of events execution in Asp.Net
Taken from http://msdn.microsoft.com/en-us/library/vstudio/ms178472(v=vs.100).aspx
PreInit
Raised after the start stage is complete and before the initialization stage begins.
Use this event for the following:
Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.
Read or set profile property values.
NoteNote If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.
Init
Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page.
Use this event to read or initialize control properties.
InitComplete
Raised at the end of the page's initialization stage. Only one operation takes place between the Init and InitComplete events: tracking of view state changes is turned on. View state tracking enables controls to persist any values that are programmatically added to the ViewState collection. Until view state tracking is turned on, any values added to view state are lost across postbacks. Controls typically turn on view state tracking immediately after they raise their Init event.
Use this event to make changes to view state that you want to make sure are persisted after the next postback.
PreLoad
Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request instance.
Load
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.
Use the OnLoad event method to set properties in controls and to establish database connections.
Control events
Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event.
Note In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing.
LoadComplete
Raised at the end of the event-handling stage.
Use this event for tasks that require that all other controls on the page be loaded.
PreRender
Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls. (To do this, the Page object calls EnsureChildControls for each control and for the page.)
The Page object raises the PreRender event on the Page object, and then recursively does the same for each child control. The PreRender event of individual controls occurs after the PreRender event of the page.
Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.
PreRenderComplete
Raised after each data bound control whose DataSourceID property is set calls its DataBind method. For more information, see Data Binding Events for Data-Bound Controls later in this topic.
SaveStateComplete
Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.
Render
This is not an event; instead, at this stage of processing, the Page object calls this method on each control. All ASP.NET Web server controls have a Render method that writes out the control's markup to send to the browser.
If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the Render method. For more information, see Developing Custom ASP.NET Server Controls.
A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.
Unload
Raised for each control and then for the page.
In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections.
For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks.
Note During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.
I'm reading up to get a better idea of how viewstate works in asp.net webforms and have been reading this article.
One part that I don't quite understand is the Stage 5 - Raise postback event, it says that this stage does not make use of any viewstate information to raise the events (ie. TextChanged).
I thought that the viewstate would be sent back with the page on the postback and after the control tree had been populated the values from the viewstate would then be loaded in and then after that the control would interrogate the new form values comparing them against the current ones loaded from viewstate in order to tell which Changed() events it needs to raise.
If this event doesn't interact with viewstate how can it tell whether a value has changed or if it is still the same from the previous load?
Daniel, you are correct in your assumption - view state is used to determine whether a change-related event needs to be raised. That includes things like the TextChanged event on the TextBox and the SelectedIndexChanged event on the DropDownList, among others.
If you haven't read this article yet, I highly recommend it: Truly Understanding View State. It's an informative write up by Dave Reed.
Thanks!
In the case of TextChanged events, it does look at the viewstate to determine if it gets raised or not - see the answer to question 6215046:
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.textbox.ontextchanged.aspx
A TextBox control must persist some values between posts to the server for this event >> to work correctly. Be sure that view state is enabled for this control.
Try enabling ViewState for TextBox.
I have searched the web for the answer and saw that mostly variables are saved in viewstate on page.prerender event. Then the value of the variable is set back in page load event.
However, when I save a variable in viewstate on prerender or load events, how can viewstate store the value of the variable after it is changed dynamically on codebehind?
Let's say, after page is loaded, user clicked a button which changes the value of the variable in its onClick event. Then the postback event raised since the button was clicked. According to me, the new value should have been lost and cannot be saved in the viewstate if the variable is saved in the viewstate only in prerender event. Because on postback the prerender event wont fire and the value cannot be saved.
Shouldn't I save the variable in the viewstate just before the postback event rises?
Am I wrong? If so, how can viewstate store the new value of the variable if the viewstate is saved in prerender event?
Thanks for the answer in advance..
I suspect you're confusing saving ViewState, ie. serializing the ViewState collection in memory to a string representation or to an intermediate object that can be serialized easily, with actually modifying that ViewState in-memory object with its regular accessor methods.
What you may be hearing is that the SaveViewState() method is called after PreRender event. But that has little to do with when you get to modify the contents of the ViewState collection.
Checkout points 7. Prerender the Objects and 8. ViewState Saved in the article The ASP.NET Page Life Cycle. There's a good MSDN article that touches on this as well.
(source: microsoft.com)
As per ASP.Net Page Lifecycle Overview (emphasis is mine)
PreLoad()
Raised after the page loads view state for itself and all controls, and after it processes postback data that is included with the Request() instance.
....
SaveStateComplete()
Raised after view state and control state have been saved for the page and for all controls. Any changes to the page or controls at this point affect rendering, but the changes will not be retrieved on the next postback.
As both Control Events and the PreRender event occur between these two, then your data should be persisted in ViewState.
Viewstate is maintained via a hidden field, so Postback has to finish before it's "set".
If you're setting it and trying to read it in the same page cycle it not going to work. You might try using the Session object, which get/sets values into memory.
I've put together a simple form to highlight the concepts of dynamic forms. What I need to do is add a control to the page when the user clicks the "Add" button.
I have a simple counter at the moment that stores the amount of controls created, which is incremented when the button is clicked.
At first I thought it would be as simple as calling RecreateChildControls (the class inherits from CompositeControl) on the event handler. This does create the new controls based on the incremented value, but all the control state is lost. I'm assuming this is because the event has been fired after the Init & Load phase.
Is there any other way to do this? I can get it to work by inspecting the postback value on the Init event, however this seems to be a little hacky.
This does create the new controls based on the incremented value, but all the control state is lost.
You're calling the function too late in the page life cycle. State is applied to your controls for the "Load" stage, and so if the controls are not created before that stage the state won't be restored, because the controls don't exist when it tries to apply the state.
You need to create the controls in the Page's Init event.
Personally, I'm not a fan of dynamic controls in ASP.Net. They have their place, but more often I choose a suitable maximum number of allowed controls, put them all on the page initially, and only enable/disable/hide/show them as needed.
Where in the page life cycle is it most appropriate to set event handler delegates for events raised by custom User Controls?
I have a ReportFilter user control that raises an ApplyFilterClicked event. Currently I am just using Page_Load to assign a handler method.
reportFilter.ApplyFilterClicked += reportFilter_ApplyFilterClicked;
If you are creating your user controls dynamically, then the most appropriate place is in the Init phase, right where the controls are created (or should be).
Otherwise, the Load phase will work just fine, and is probably where most people set them. Obviously, you can't set the handlers anywhere later than that, otherwise they would never be called, since the event handling phase is next in line after Load.
Usually the init phase is best for creating controls because this will help with viewstate updates to the controls. Check out this page for some good info on page lifecycle:
http://msdn.microsoft.com/en-us/library/ms178472.aspx
Hope this helps