Even though the server controls are not seen as yet, you can see the Button control on line 13, which has a Click event. This event posts information to the server and executes the Button1_Click method, which is defined in the code declaration block on lines 4-6.
Particular notice line no 5:
5: Label1.text= “You Clicked <b>” & obj. Text & “</b>”
This line sets the Text property of the control named Label1 (the Label on line 1) to whatever is specified after the equal sign. Obj is the name of the parameters. Since you know it represents the Button, you can grab its Text property as well.
Line 13, shows that the Button’s text property is set to My Button which will be displayed on the browser as output.
The second parameter in your method, e, currently contains no information because the control Button had nothing else to send. However, it has to be included because it forms a part of the standard event parameter list.
Thus, you can handle events accordingly by providing them with appropriate methods to handle them. You can use the event handler out for the events that you want to ignore. This method allows you to handle many different events. Nothing stops you from creating 20 Button controls with reference to the same method.
Posting Web Forms
Imagine a typical ASP.NET scenario. Whenever the page loads into the browser, a welcome message is displayed in a server control. This message however becomes a part of the control’s viewstate (as discussed previously), and ASP.NET remembers it automatically.
Then the user submits the form, or an event occurs that causes a post to the server. The server then processes any data or event it needs and sends the page back to the client for display.
Since ASP.NET remembers the viewstate for the control, it automatically fills in the welcome message again without any type of intervention. This is the same for user entered information. If a user enters her name in a text box, she’ll find that the entered text remains in the box even after the form is submitted. Thus this is a welcome change from traditional HTML forms, where the values were lost upon every post.
Therefore, refilling the server controls’ values after the form is posted is not needed any more as ASP.NET performs the task.
The Page object has a property called IsPostBack that tells the status of the form i.e. checks whether or not the form has already been posted. This property helps you to keep a check on the status of the form as well decide whether to fill in server controls. For example, let’s take a look at this Example.
< %@ Page Language= “VB”>
<script runat= “server”>
Sub Page_Load (obj as object e as EventArgs)
if not Page.IsPostBack then
lblMessage. Text = “Hello world!!!!”
Sub Submit (obj as object e as EventArgs)
lblMessage2. Text = “Form has been posted”
<form runat= “server”>
<asp: Button id= “btSubmit” runat= “server” Text= “Submit”
onClick= “Submit” />
<asp: Label id= “lblMessage” runat=server />
<asp: Label id = “lblMessage2” runat=server/>
The output is shown below: -
In the above example when this page loads, the words “Hello World!!!!” will be displayed in the label on line 20. When the user clicks the Submit button, “Form has been posted” will appear in the second label on line 22. The first label will still have the hell message because ASP.NET saves it in the viewstate and automatically fills it.
IsPostBack property is checked on line 5, and if it’s true (meaning the form has been submitted), there is no need to execute line 6. No refilling of the label is required every time the form is posted because ASP.NET does it.