When I work today, I need to determine whether a pop-up window is displayed based on the specific content of the gridview. The gridview contains paging and sorting, and they cannot be simply analyzed from the query string or form. This is because the _ dopostback method exists and the _ eventtarget and _ eventargument closely related to it.
When you use Asp.net to develop a webpage, the HTML code of the webpage contains the _ dopostback method of the following code:
<SCRIPT type = "text/JavaScript">
<! --
VaR theform = Document. Forms ['form1'];
If (! Theform ){
Theform = Document. form1;
}
Function _ dopostback (eventtarget, eventargument ){
If (! Theform. onsubmit | (theform. onsubmit ()! = False )){
Theform. _ eventtarget. value = eventtarget;
Theform. _ eventargument. value = eventargument;
Theform. Submit ();
}
}
// -->
</SCRIPT>
Only two web server controls trigger the page's PostBack. All other controls trigger the page's PostBack through the _ dopostback function, during page parsing, A _ dopostback (eventtarget, eventargument) method is generated for this class. Eventtarget is the ID of the control that causes sending back, And eventargument is the callback parameter (additional data related to the control ). The two parameters are saved by the hidden form fields _ eventtarget and _ eventargument. You can use these two hidden forms to find the control ID and parameters that cause the page delivery.
When you trigger the _ dopostback event, traverse this. Request. Form. allkeys and you can see these two hidden forms.
Because the content finally presented to the browser is HTML content, the use of Asp.net technology is no exception. To implement the webcontrol PostBack mechanism, you can only post on the original submit.
I can see that Asp.net now adds two hidden inputs to the page, which are used to store the IDs and parameters of the control that triggers PostBack. This is what most of us realize:
The first parameter of _ dopostback (obj1, obj2) is the Control ID, and the second parameter is the PostBack parameter. then you can use the request in the background. form ["_ eventtarget"] and request. form ["_ eventargument"] obtains the Control ID and parameters.
It's easy to implement what seems amazing, and think there is a profound internal processing process! This lightweight implementation of the Asp.net PostBack mechanism is admirable! As long as we understand the above Code, the use of _ dopostback should not be difficult. It can be said that _ dopostback is such a simple thing.-_-|
However, in Asp.net's webcontrols, buttons and imgbutton are different. They do not use _ dopostback to implement PostBack. in this case, it may be because the button already has the function to trigger the submit event in HTML. .asp.net is just to make the original HTML something that cannot trigger the submit, _ dopostback is implemented. for the button that can be used to submit, why bother to do so.
The button can be found in the background using the above method. Why? I don't know. during the button submission process, the button uses the ID of the button as the request. A key of form. Its value is the text attribute value of the button and is returned to the server. therefore, you can cycle form in the background. keys obtains the submitted button to execute the corresponding function. imgbutton is similar. The difference is that it does not use the ID of imagebutton as the request. form key, which is added with the ID of imagebutton. X and. Y as the key, in the request. form adds two key-value pairs, which correspond to the image size of imagebutton. After understanding this rule, we can still determine whether the PostBack is caused by imagebutton in a certain way.