Aspx page event execution sequence

I. Details
L Initialization
2. When the page is submitted, the first method is always the constructor. You can initialize some custom attributes or objects in the constructor, but at this time, the page is not fully initialized, so there are some restrictions. In particular, you need to use the HttpContext object. Currently, you can use QueryString, Form, Cookies, and Cache objects. Note: Session is not allowed in constructors.

2. The next method to be executed is the AddParsedSubObject method. This method adds all independent controls and forms a control set tree on the page, this method is often overwritten by some advanced Page Template Solutions to add Page content to some special controls in the Page Template. This method is recursively applied to all page controls and each corresponding sub-control. All controls start the earliest initialization in this method.

2. The next method to be executed in the page class is DeterminePostBackMode. This method allows you to modify the IsPostBack value and related events. This method is especially useful if you need to load ViewState from the database, because ViewState can be restored only when IsPostBack is true. If the return value is null, a non-return Request is forcibly executed. If the return value is Request. Form, a return Request is forcibly executed. Unless in special circumstances, it is not recommended to operate this operation, because this will affect other events.

2. The next method to be executed is the OnInit method, which is generally the first method actually used. When this method is triggered, all controls in the page definition execute initialization, which means that all the values defined in the page are applied to the corresponding controls. However, ViewState and returned values are not applied to the control. Therefore, no value changed by code or users has been recovered to the control. This method is usually the best place to create and recreate dynamic controls.
L restore and Load
2. In the next method, LoadPageStateFromPersistenceMedium is executed only when the page is returned. If you modify the SavePageStateToPersistenceMedium method that will affect ViewState storage because of Session or custom storage, this method needs to be overwritten. By default, ViewState is encoded in Base64 format and saved in the hidden domain of the page. You can modify ViewState by using the methods mentioned in this article. Note: This method does not actually load ViewState to a page or page control.

2. After ViewState is obtained, the next method LoadViewSate will recursively restore ViewState to the page and various page controls or child controls. After this method is executed, each control is restored to the last 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 mainly used to restore the value of the control that you dynamically generated in other events. The value is manually saved in ViewSate and is invalid now.

2. The next method is ProcessPostData. This method is executed only when it is returned and cannot be overwritten. This is a private method of the page base class. This method restores the value of the control submitted by the user by matching the control name. This step means that the entire page has been completely restored. The only thing to remember is that all dynamic controls must be created before this method. This method is also used to record subsequent event changes.

2. The next method is the OnLoad method, which is usually the most commonly used method, because this method is the first place to restore all values in the page lifetime. Most Code determines whether to reset the control status based on 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 the methods of the control will be executed to catch up with the status of the current page, including ViewSate, but not the return value.
L event processing
2. The next method is ProcessPostData, which is actually another call of the previous method. It is still executed only during the callback and cannot be overwritten because it is a private method. If this is the first time you read the running track of the page, you may find this method redundant. But in fact, this method is necessary because the dynamic controls created in OnLoad also need their return values. Any controls created after this will be able to get their ViewState, but will no longer get their return value, and will not trigger any value Change Event ).

2. The next method, RaiseChangedEvents, is executed only on the return page, and cannot be inherited because it is a private method of the base class. During the lifecycle of the entire page, this event is triggered based on whether the value of the control recorded in the previous ProcessPostData is different from the submitted value. You may need to call Validate or check the value of IsValid. Here, there is no special description that multiple values change the event execution sequence.

2. The next method, RaisePostBackEvent, is also because the private method of the base class cannot be inherited and is only executed on the return page. Unless AutoPostBack is used, this is where the actual form submission event is executed, especially when buttons or javascript is used to submit the form. If the verification control has not been manually called and is used, the Validate is called. Note that a BUG in IE sometimes allows submission but does not trigger any event.

2. The next method is OnPreRender. Generally, this is the last chance to change the page and its controls before the client displays the page. You can also create a dynamic control in this method, and all the methods will be executed to catch up with the status of the current page including ViewSate, but the private method will not be executed, this means that no value is returned and no event is triggered. Due to the BUG in IE, this is a good place to catch up with PostBack without events.
L save and display
2. The next method is SaveViewState. Whether it is a return page or not, it is recursively executed to save the ViewState of the page and all its controls. ViewState basically stores all values different from the original values defined in aspx, whether changed by code or users. Note that the control values are saved based on their locations in the control tree of the page. Therefore, if the dynamic control is subsequently added to an incorrect position, confusion may occur.

2. The next method is SavePageStateToPersistenceMedium to save the page's ViewSate. This method is overwritten along with LoadPageStateFromPersistenceMediumg to save ViewState to Session or other custom data, rather than hiding the domain. This is very helpful for low-bandwidth users. In addition, Session is the default setting for mobile devices. The following article describes how to save ViewState using the preceding two methods. Note that there is a Bug in Asp.net: Asp.net requires that the _ viewstate field be submitted, even if it is null.

2. The next method is the Render method, which recursively creates and sends the html of the corresponding control to the browser. This method is rewritten by some Page Template schemes to add some general page headers and feet without using server controls. They always have some additional things. Note that only HTML can be used for modification here, because the control has been generated here. You can use StringBuilder, StringWriter, and HtmlTextWriter to capture the corresponding HTML output.

2. The final method is OnUnload, which calls the corresponding Dispose method. This method provides an opportunity to clear the unmanaged resources used on the page, such as closing the opened file handle and previously opened database connections. Note that this method is executed after the page has been sent to the client, so it only affects the Server Object and will not be displayed in the display track of the page. This is the lifetime of the page, which is run for every request.

Ii. Lite version

Page is activated in the following order: Page. preInit ----> Page. init ----> Page. initComplite ----> Page. preLoad ----> Page. load ----> Page. loadComplete ----> Page. preRender ---->

Page. PreRenderComplete

If a page is inherited from a page, such as BasePage: System. web. UI. page, some extensions are made in the BasePage, such as permission check. When other pages inherit from the BasePage, the order of activation of the events of the BasePage and the final Page is:

UI. preInit ----> Page. preInit ----> UI. init ----> Page. init ----> UI. initComplite ----> Page. initComplite ----> UI. preLoad ----> Page. preLoad ----> UI. load ----> Page. load ----> UI. loadComplete ----> Page. loadComplete ----> UI. preRender ----> Page. preRender ----> UI. preRenderComplete ----> Page. preRenderComplete

If MasterPage is used, the events in MasterPage and those in ContentPage are activated in the following order:

ContentPage. PreInit

Master. Init

ContentPage. Init

ContentPage. InitComplite

ContentPage. PreLoad

ContentPage. Load

Master. Load

ContentPage. LoadComplete

ContentPage. PreRender

Master. PreRender

ContentPage. PreRenderComplete

Furthermore, if ContentPage inherits the BasePage, the execution sequence of each event is changed:

UI. PreInit

ContentPage. PreInit

Master. Init

UI. Init

ContentPage. Init

UI. InitComplite

ContentPage. InitComplite

UI. PreLoad

ContentPage. PreLoad

UI. Load

ContentPage. Load

Master. Load

UI. LoadComplete

ContentPage. LoadComplete

UI. PreRender

ContentPage. PreRender

Master. PreRender

UI. PreRenderComplete

ContentPage. PreRenderComplete