Now, starting from the execution sequence of ASP. NET pages, let's take a look at the characteristics of the B/S structure program. The execution sequence of ASP. NET pages is described as follows:
Page_Init (events triggered by PAGE initialization) --> Page_Load (events triggered when a page is loaded) --> Control Event (events triggered by a Server Control) --> Page_UnLoad (events triggered when the page is detached from the memory)
Page_Init and Page_UnLoad are not commonly used. The difference between the Page_Init and Page_Load events is that only the latter can fully load the control and bind data. Although you can access the control in Page_Init, its viewstate will not be loaded, therefore, only the default value is available in the control.
The viewstate is mentioned here. Let's take a rough look at it-in fact, there are two viewstates in ASP. NET. One is the control itself, which is used to maintain some states of the control. For example, if a space has a color changing function, its viewstate maintains this function. This viewstate cannot be accessed by users. I believe that all my friends who have written controls will feel this way. Of course, they will also use their own viewstate to maintain the status of the control. The other viewstate is used by users, this viewstate is almost the same as the Session, and must be defined before it can be used.
Every time you click a Button, LinkButton, or ImageButton control on an ASP. NET Web page, the form is sent to the server. If the AutoPostBack attribute of some controls is set to true, after the control's status is changed, the form will also be sent back to the server .? (AutoPostBack attribute, which has only two bool values, true/false. If this attribute is set to false, the changes will not be immediately transmitted to the server for processing after the click, and the SelectedIndexChanged event of the control will not exist .)
Each time a form is sent back to the server, it is reloaded, The Page_Load event is started, and all code in the Page_Load event processing program is executed (note that it is executed every time !).
Obviously, it is most appropriate to put the webpage initialization code here. We often want to execute some code every time a webpage is loaded, such as data binding of some controls.
When we want to execute some other code only when the webpage is loaded for the first time (basically the default binding of data), we even want some code to be executed at each load except for the first load. We can use the IsPostBack feature to complete this function. When a webpage is loaded for the first time, the value of this attribute is false. If the webpage is reloaded due to sending back, the value of the IsPostBack attribute is set to true.
In ASP. NET applications, if you need to perform initialization operations when the page is displayed for the first time, you must determine the IsPostBack attribute!
In ASP. NET use Page. isPostback, you can avoid extra work on the round-trip: If you process the Server Control to send back, you usually need to execute the code on the first request page, this code is different from the code used for round-trip when an event is triggered. If check? Page. IsPostBack? The code can be executed according to the conditions, depending on whether there is an initial request to the page or a response to the server control event. This seems obvious, but you can ignore this check without changing the page behavior. The usage of this attribute is directly related to whether your program runs as expected, and the efficiency of the entire page. Because, if you bind data to the control every time, no matter whether you access the control for the first time or submit the data, the efficiency of the page program can be imagined.
Each time a page with a B/S structure is submitted, it will be executed again from start to end. The C/S structure program won't be like this. This is the biggest difference with the C/S structure program !? In fact, the data of the control is not obtained for this reason.
From: http://www.donews.net/shanyou/archive/2004/04.aspx