Asp. NET page events: sequence and return details

First, initialization

• The first method is always a constructor when a page is submitted for request. You can initialize some custom properties or objects in the constructor, but there are some limitations because the page has not yet been fully initialized. In particular, you need to use the HttpContext object. Currently available objects include QueryString, form, and cookies collection, as well as cache objects. Note: The session is not allowed in the constructor.

• The next method to be executed is the AddParsedSubObject method, which adds all the separate controls and makes the page into a control collection tree, which is often used by some Advanced page template Solutions (page Template Solutions) Rewrite to add page content to some special controls in the page template (page Template). This method recursively applies to all page controls and each of the corresponding child controls, all of which begin with the earliest initialization in this method.

• The next method to be executed in the page class is DeterminePostBackMode. This method allows you to modify IsPostBack values and related events. This method is particularly useful if you need to load viewstate from a database, because ViewState only recovers if IsPostBack is true. Returning null will result in a forced execution of a non-postback, and the return Request.Form force a postback. This is not recommended unless it is in exceptional circumstances, because it can also affect other events.

• The next method to be executed is the OnInit method, which is generally the first method that is actually used. When this method fires, the controls in all page definitions perform initialization, 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 values that are changed by the code or user have not been restored to the control. This method is usually the best place to create and re-create dynamic controls.

Ii. Recovery and loading

• Next method, LoadPageStateFromPersistenceMedium will only be executed when the page is returned. This method needs to be overridden if you modify the method savepagestatetopersistencemedium that will affect the ViewState save mode later, because you are using session or custom storage. The default implementation viewstate is a Base64 format encoding and is saved in the hidden field of the page, and you can use the method mentioned in this article to modify viewstate in both of these ways. Note: This method does not actually load viewstate into the page or page control.

• When ViewState is obtained, the next method Loadviewsate, recursively restores viewstate to pages and individual page controls or child controls. Once this method is executed, each control reverts to the previous state, but the data submitted by the user has not been applied to the control because they are not part of the viewstate. This method is primarily used to restore the values of controls that you dynamically generated in other events, whose values you manually save in Viewsate and are now invalidated.

• The next method is Processpostdata, and this method is also performed when it is returned, and is not allowed to be overridden, which is a private method of the page base class. 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 keep in mind is that all dynamic controls must be created before this method. This method is also the way to record subsequent changes to the event.

• The next method is the OnLoad method, which is usually the most frequently used method because it is the first place in the page lifetime that restores all values. Most code determines whether the control state is reset based on the ispostback of the judgment. You can also call validate in this method and check the value of the IsValid. You can also create a dynamic control in this method, and all of the control's methods are executed to catch up with the current page's state including Viewsate, but not the return value.

Iii. Handling of events

• The next method, or Processpostdata, is actually another call to the previous method, which is still executed only at the time of the postback and is not allowed to be overridden because it is a private method. If this is the first time you look at the trajectory of a page, you may find this method superfluous. But actually this method is necessary because the dynamic controls created in onload also need the values they return. Any controls created after this will be able to get their viewstate, but they cannot get their return value and will not trigger any value change event.

• The next method, Raisechangedevents, is also performed only in the return page, and because it is a private method of the base class, all cannot be inherited. Throughout the lifetime of the page, it is here to trigger a value change event based on whether the value of the control recorded by the previous processpostdata is different from the committed value. You may need to call validate or check the value of IsValid. There is no particular description of how multiple values change the execution sequence of events.

• The next method, RaisePostBackEvent, is also because the private method of the base class cannot be inherited, and is only executed in the return page. Unless you are using AutoPostBack, this is where you actually submit the form event execution, especially the button or actually use JavaScript to submit the form. If it has not been manually invoked and the validation control is used, then validate will be invoked. Note that there is a bug in IE that sometimes allows submission but does not trigger any events.

• The next method is OnPreRender, which is generally the last chance to change the page and its controls before the client presents the page. You can also create dynamic controls within this method, and all methods will be executed to catch up with the current page's state including Viewsate, but the private method will not be executed, meaning there will be no return value and no event triggering. Because of the bug in IE, this is a good place to catch postback without incident.