Asp. NET page events: sequence and callbacks

The first method is always the constructor when the page is submitted for a request. You can start some custom properties or objects inside the constructor, but this is somewhat limited because the page is not fully initialized. In particular, you need to use the HttpContext object. Currently available objects include QueryString, form, and a collection of cookies, as well as the cache object. Note: The session is not allowed in the constructor.

The next method to be executed is the AddParsedSubObject method, which will add all the standalone controls and make the page a control collection tree, which is often used by some Advanced page template Solutions (page templates Solutions) Override to add page content to some special controls in the page template. This method recursively applies to all page controls and to each of the corresponding child controls, all of which begin with the earliest initialization in this method. http://hovertree.com/menu/aspnet/

The next method that will be executed in the page class is DeterminePostBackMode. This method allows you to modify the value of the IsPostBack and related events. This method is particularly useful if you need to load viewstate from a database, because ViewState is only recoverable if IsPostBack is true. Returning NULL will cause a non-postback to be enforced, and returning Request.Form forces a callback to be performed. Unless in exceptional circumstances, it is not recommended to operate this, as this will also affect other events.

The next method to be executed is the OnInit method, which is generally the first really used method. When this method is triggered, all controls in the page definition are initialized, which means that all values defined in the page are applied to the corresponding control. However, viewstate and return values are not applied to the control, so any value changed by the code or user has not been restored to the control. This method is often the best place to create and recreate dynamic controls.

Second, recovery and loading

The next method, LoadPageStateFromPersistenceMedium will only be executed when the page is returned. This method needs to be rewritten if you modify the method savepagestatetopersistencemedium that will affect viewstate save by using the session or custom storage method. In the default implementation, ViewState is a Base64 format encoding and is saved in the hidden field of the page, and you can use the methods mentioned in this article to modify the ViewState to save it in either of these ways. Note: This method does not actually load viewstate into a page or page control.

When the viewstate is obtained, the next method Loadviewsate, recursively restores viewstate to the page and to the individual page controls or child controls. Once this method executes, each control reverts to the last state, but the data submitted by the user has not yet been applied to the control because they are not part of the viewstate. This method is primarily used to restore the values of the controls that you dynamically generate in other events, and their values are stored manually in Viewsate and are now invalidated.

The next method is Processpostdata, this method is also the return of the time will be executed, and is not allowed to be rewritten, this is the page base class private method. This method restores the value of the corresponding user-submitted control by matching the name of the control, which means that the entire page has been fully restored. The only thing to remember is that all dynamic controls must be created before this method. This method is also a way to record the change of events that follow.

The next method is the OnLoad method, which is usually the most used method, because this method is the first place in the page lifetime where all values have been restored. Most code determines whether to reset the control state by judging IsPostBack. You can also call validate in this method and check the value of IsValid. You can also create a dynamic control in this method, and all of the methods of the control will be executed to catch up with the current page's state including Viewsate, but not the value of the callback.

Iii. Handling of events

The next method, or Processpostdata, is actually another call to the previous method, which is still only executed at the time of the callback and is not overridden because it is a private method. If this is the first time you look at the running track of a page, you might find this method somewhat superfluous. But in practice this method is necessary because the dynamic controls created in onload also require values for their callbacks. Any controls created after this will be able to get their viewstate, but they can no longer get the value of their callbacks and will not trigger any value change events.

The next method, Raisechangedevents, is also executed only in the callback page, and also because it is a private method of the base class, all cannot be inherited. Throughout the page lifetime, it is here that the value change event is triggered based on the value of the control that was recorded by the previous processpostdata and whether the value submitted is different. You may need to call validate or check the value of IsValid. There is no particular explanation for the order in which multiple values change events.

The next method, RaisePostBackEvent, is also because the private method of the base class cannot be inherited and is also executed only in the callback page. Unless AutoPostBack is used, this is where the actual submission of the form event executes, especially the button or the fact that the form is submitted using JavaScript. If it has not been manually invoked and the validation control is used, then validate will be called. Note that there is a bug in IE that sometimes allows submissions but does not trigger any events.

The next method is OnPreRender, which is typically the last opportunity to change the page and its controls before the client presents the page. You can also create dynamic controls in this method, and all methods will be executed to catch up with the state of the current page, including Viewsate, but the private method will not be executed, which means there will be no callback values and no event triggers. Because of the bug in IE, this is a good place to catch up with postback without an event.

Recommendation: http://www.cnblogs.com/roucheng/p/netkuangjia.html

Asp. NET page events: sequence and callbacks