. NET page events

Contact. net is very important. The operations in B/S are basically dealing with pages. NET page, as well as the events and methods that occur in a cycle, we should understand.

For each page executed, we must perform the following operations on the webpage in. Net:

# Function description of an event or Method

1. initialize the initialization settings on the init event page.

2. The loadviewstate method loads the viewstate filling property.

3. The loadpostdata method is used to process the returned data and input form data.

4 load event page control Initialization is complete and reflects the client data.

5. The change event is triggered when the raisepostdatachangedevent method sends a change notification.

6. The raisepostbackevent method is used to process the client events that cause sending back events, and the corresponding time is triggered on the service.

7 prerender event page pre-rendering
8. The saveviewstate method saves the viewstate attribute to a string.

9 render method rendering page
10 whether the dispose method handles references to expensive resources.

11 unload event uninstall page

1. initialize the object
A page control (and the page itself) should be correctly initialized at first. By calling all objects in the constructor of your C # file, the page will know how many objects to be created and their types. Once you name all objects in your constructor, you can access them by inheriting classes, methods, events, or attributes. However, if some of your objects are some controls specified in the aspx file, these controls have no attributes. At the same timeCodeAccess to them may cause some unexpected errors because these control instances do not have a definite order of creation (if they are created together ). In addition, you can use oninit to reload initialization events.

Ii. Import viewstate data
After the initialization event, all controls can only be accessed by referencing their IDs (because there is no corresponding Dom available ). In the loadviewstate event, all controls get their first property: viewstate. This attribute will be returned to the server to determine whether the page has been accessed by the user or is still being accessed by the user. The viewstate attribute is saved as a string of the "name/value" pair. It contains the control text, value, and other information. This property is stored in the value property of a hidden <input> Control and passed on the request page. This method is much more advanced than how asp3.0 maintains and judges the page status. In addition, you can reload the loadviewstate event function to set the value of the corresponding control.

3. Use loadpostdata to process PostBack data
At this stage of page creation, the server processes the form data submitted by the control on the page (called PostBack data in Asp.net. When a page submits a form, the Framework executes an ipostbackdatahandler interface operation on each control that submits data. Then, the page executes the loadpostdata event, parses the page, finds each control that executes the ipostbackdatahandler interface operation, and updates the status of these controls with the appropriate PostBack data. Asp.net performs this operation by matching the unique ID of each control with the "name/value" pair in the namevalue set. Therefore, on the Asp.net page, each control must have a unique ID, and several controls cannot have a common ID. Even some custom controls, the framework will grant them unique IDs. After loadpostdata event, execute the following raisepostdatachanged event.

Iv. Import objects
In the load event, all objects are instantiated. For the first time, all objects are placed in the DOM page (called the control tree in Asp.net) and can be referenced through code or related locations. In this way, the object can easily obtain attribute values in HTML from the client, such as width, height, value, and visibility. In the load event, operations such as setting control properties also occur. This process is the most important and important throughout the lifecycle. You can call onload to reload events.

5. raisepostbackchanged event
As mentioned above, this event occurs after all controls perform the ipostbackdatahandler interface operation and are updated by the correct PostBack data. In this process, each control is assigned a Boolean value to indicate whether the control has been updated. Then, Asp.net searches for any updated controls on the entire page and executes the raisepostdatachanged event operation. However, this event is performed only after all controls are updated and the load event is complete. This ensures that other controls will not be manually changed in the raisepostdatachanged event before being updated by the PostBack data.

6. Process client PostBack events
When all events caused by PostBack data on the server are completed, the object that generates the PostBack data executes the raisepostbackevent event operation. In this case, the status of a control changes, so that it returns the form to the server or the user clicks the submit button to return the form to the server. In this case, there should be corresponding processing code to reflect the event-driven object-oriented programming principle. To meet the data accuracy requirements presented to the browser, the raisepostbackevent event is the final occurrence in a series of PostBack events.
Controls changed during the PostBack process should not be updated after function execution is called. That is to say, any data changed due to an expected event should be reflected on the final page. You can modify the raisepostbackevent function to meet your requirements.

VII. Pre-Submission objects
This step is the last time the object can be changed and saved-the pre-submitted object. In this way, you can make the final modification to the properties and tree structure of the control. At the same time, you do not need to consider making any changes to Asp.net, because it is out of the database call and viewstate update. After this step, all modifications to the object will be final and cannot be saved to the viewstate of the page. You can use onprerender to reload this step.

8. Save viewstate
After all the page controls are modified, the viewstate is saved. The status data of the object is still stored in the hidden <input> control. The object status data presented to HTML is also obtained from here. In the saveviewstate event, the value can be saved to the viewstate object. However, the modification of the control on the page cannot be performed. You can use saveviewstate to reload this step.

9. Submit to HTML
The render event occurs when a page is created using HTML to be output to the browser. During the render event process, the objects in the page are called to submit them to HTML. Then, the page can be accessed by the user's browser in the form of HTML. When a render event is overloaded, developers can write custom HTML code to make the originally generated HTML invalid and organize pages according to the new HTML. The render method uses an htmltextwriter object as a parameter and uses it to display HTML in the browser as a webpage. Some modifications can be made at this time, but they are only some changes on the client. You can reload the render event.

10. Destroy objects
After being submitted to HTML, all objects should be destroyed. In the dispose event, you should destroy all the objects created when this page is created. At this time, all the processing has been completed, so the destruction of any remaining objects will not produce errors, including page objects. You can reload the dispose event.