What are the different levels at which events can occur in an ASP.NET web application?
Web application events occur at the application, page, and server control levels
Give some examples of application-level events?
1. Application_Start
This occurs when the first user visits a page within your Web application.
2. Application_End
This occurs when there are no more users of the application.
3. Application_BeginRequest
This occurs when at the beginning of each request to the server. A request happens every time a browser navigates to any of the pages in the application.
4. Application_EndRequest
This occurs when at the end of each request to the server.
5. Session_Start
This occurs when a new user visits a page within your application.
6. Session_End
This occurs when a user stops requesting pages from the Web application and their session times out. Sessions time out after a period specified in the Web.config file.
7. Application_Error
This occurs when there is an unhandled exception in an application.
Where are the application-level event handlers present in an ASP.NET web application?
Application-level event handlers are present in Global.asax of an ASP.NET web application
What is the difference between Application and Session Events?
At an application level, we can have Application and Session events. Use Application events to initialize objects and data that you want to make available to all the current sessions of your Web application. Use Session events to initialize data that you want to keep throughout individual sessions, but that you don’t want to share between sessions.
Give some examples of application-level events?
1. Application_Start
This occurs when the first user visits a page within your Web application.
2. Application_End
This occurs when there are no more users of the application.
3. Application_BeginRequest
This occurs when at the beginning of each request to the server. A request happens every time a browser navigates to any of the pages in the application.
4. Application_EndRequest
This occurs when at the end of each request to the server.
5. Session_Start
This occurs when a new user visits a page within your application.
6. Session_End
This occurs when a user stops requesting pages from the Web application and their session times out. Sessions time out after a period specified in the Web.config file.
7. Application_Error
This occurs when there is an unhandled exception in an application.
Where are the application-level event handlers present in an ASP.NET web application?
Application-level event handlers are present in Global.asax of an ASP.NET web application
What is the difference between Application and Session Events?
At an application level, we can have Application and Session events. Use Application events to initialize objects and data that you want to make available to all the current sessions of your Web application. Use Session events to initialize data that you want to keep throughout individual sessions, but that you don’t want to share between sessions.
Give an example of how to use Application and Session events?
To see how Application and Session events occur, add the following code to the Global.asax file in a Web forms project.
void Application_Start(object sender, EventArgs e)
{
// Create Application state variables.
Application["AppCount"] = 0;
Application["SessCount"] = 0;
// Record application start.
Application["AppCount"] = (int)Application["AppCount"] + 1;
}
void Session_Start(object sender, EventArgs e)
{
// Count sessions.
Application["SessCount"] = (int)Application["SessCount"] + 1;
}
void Session_End(object sender, EventArgs e)
{
// Decrement sessions.
Application["SessCount"] = (int)Application["SessCount"] - 1;
}
Add the following code to WebForm1.aspx file in a Web forms project and set WebForm1 as start-up page.
protected void Page_Load(object sender, EventArgs e)
{
// Display Application count.
Response.Write("Number of applications: " +
Application["AppCount"] + "
");
// Display session count.
Response.Write("Number of sessions: " +
Application["SessCount"] + "
");
}
To demonstrate the events, run the preceding code, and then start a new instance of the browser and navigate to the address. Each new instance of the browser increments the session count, but the application count stays at 1.
How long a webform instance is available on the webserver?
Web forms live for barely a moment. When we request a web form from the browser, the applications executable creates an instance of the requested Webform, generates the HTML to respond to the request, and posts that respond to the browser. It then destroys the instance of the Web form.
When the client browser has the generated HTML, the user can type text in boxes, select options, and perform other tasks until triggering a postback event, such as a button click. Postback events cause the browser to send the page’s data (view state) back to the server for event processing. When the server receives the view state, it creates a new instance of the Webform, fills in the data from the view state, and processes any events that occurred. As soon as the server has finished, it posts the resulting HTML back to the browser and destroys the instance of the Web form.
Give some examples of page-level events and when they occur?
1. Page_Init
During Page_Init the server controls are loaded and initialized from the Web form’s view state. This is the first step in a Web form’s life cycle.
2. Page_Load
During Page_Load the server controls are loaded in the Page object. View state information is available at this point, so this is where you put code to change control settings or display text on the page.
3. Page_PreRender
During Page_PreRender the application is about to render the Page object.
4. Page_Unload
During Page_Unload the page is unloaded from memory.
5. Page_Disposed
During Page_Disposed the Page object is released from memory. This is the last event in the life of a Page object.
6. Page_Error
Page_Error event is raised when an unhandled exception occurs.
7. Page_AbortTransaction
Page_AbortTransaction is raised when a transaction is aborted.
8. Page_CommitTransaction
Page_CommitTransaction is raised when a transaction is committed.
9. Page_DataBinding
Page_DataBinding occurs when a server control on the page binds to a data source.
What is the order in which Page-level events occur?
IsPostback property of the Page class.
What are the 3 types of Server Control Events?
Server controls, such as a Button, TextBox, and DropDownList, each have their own sets of events that occur in response to user actions. However, not all server control events are created equal. There are three types of server control events as listed below.
Postback events :
These events cause the Web page to be sent back to the server for immediate processing. Postback events affect perceived performance because they trigger a round-trip to the server. A Button control triggers a postback event. A dropdown list can also trigger a postback if the AutoPostBack property of the DropDownList is set to true, else a dropdownlist triggers a cached event. The same is the case with a TextBox.
Cached events :
These events are saved in the page’s view state to be processed when a postback event occurs. A DropDownList and a TextBox can trigger a cached event if the AutoPostBack property is set to false.
Validation events :
These events are handled in the page without posting back or caching. The validation server controls use these types of events.
How can you convert a Cached event of control to a postback event?
You can convert a Cached event of control to a postback event by setting the AutoPostBack property to true.
What is the order in which events are executed?
The validations controls are evaluated before the page is posted back to the server. When the page is posted back, the Page_Init and Page_Load events are handled, then cached events are handled, and finally, the event that caused the postback is processed. Among cached events, the event order is determined by the order of the controls on the Web form.
To see how Application and Session events occur, add the following code to the Global.asax file in a Web forms project.
void Application_Start(object sender, EventArgs e)
{
// Create Application state variables.
Application["AppCount"] = 0;
Application["SessCount"] = 0;
// Record application start.
Application["AppCount"] = (int)Application["AppCount"] + 1;
}
void Session_Start(object sender, EventArgs e)
{
// Count sessions.
Application["SessCount"] = (int)Application["SessCount"] + 1;
}
void Session_End(object sender, EventArgs e)
{
// Decrement sessions.
Application["SessCount"] = (int)Application["SessCount"] - 1;
}
Add the following code to WebForm1.aspx file in a Web forms project and set WebForm1 as start-up page.
protected void Page_Load(object sender, EventArgs e)
{
// Display Application count.
Response.Write("Number of applications: " +
Application["AppCount"] + "
");
// Display session count.
Response.Write("Number of sessions: " +
Application["SessCount"] + "
");
}
To demonstrate the events, run the preceding code, and then start a new instance of the browser and navigate to the address. Each new instance of the browser increments the session count, but the application count stays at 1.
How long a webform instance is available on the webserver?
Web forms live for barely a moment. When we request a web form from the browser, the applications executable creates an instance of the requested Webform, generates the HTML to respond to the request, and posts that respond to the browser. It then destroys the instance of the Web form.
When the client browser has the generated HTML, the user can type text in boxes, select options, and perform other tasks until triggering a postback event, such as a button click. Postback events cause the browser to send the page’s data (view state) back to the server for event processing. When the server receives the view state, it creates a new instance of the Webform, fills in the data from the view state, and processes any events that occurred. As soon as the server has finished, it posts the resulting HTML back to the browser and destroys the instance of the Web form.
Give some examples of page-level events and when they occur?
1. Page_Init
During Page_Init the server controls are loaded and initialized from the Web form’s view state. This is the first step in a Web form’s life cycle.
2. Page_Load
During Page_Load the server controls are loaded in the Page object. View state information is available at this point, so this is where you put code to change control settings or display text on the page.
3. Page_PreRender
During Page_PreRender the application is about to render the Page object.
4. Page_Unload
During Page_Unload the page is unloaded from memory.
5. Page_Disposed
During Page_Disposed the Page object is released from memory. This is the last event in the life of a Page object.
6. Page_Error
Page_Error event is raised when an unhandled exception occurs.
7. Page_AbortTransaction
Page_AbortTransaction is raised when a transaction is aborted.
8. Page_CommitTransaction
Page_CommitTransaction is raised when a transaction is committed.
9. Page_DataBinding
Page_DataBinding occurs when a server control on the page binds to a data source.
What is the order in which Page-level events occur?
- Page_Init
- Page_Load
- Page_PreRender
- Page_Unload
- Page_Disposed
IsPostback property of the Page class.
What are the 3 types of Server Control Events?
Server controls, such as a Button, TextBox, and DropDownList, each have their own sets of events that occur in response to user actions. However, not all server control events are created equal. There are three types of server control events as listed below.
Postback events :
These events cause the Web page to be sent back to the server for immediate processing. Postback events affect perceived performance because they trigger a round-trip to the server. A Button control triggers a postback event. A dropdown list can also trigger a postback if the AutoPostBack property of the DropDownList is set to true, else a dropdownlist triggers a cached event. The same is the case with a TextBox.
Cached events :
These events are saved in the page’s view state to be processed when a postback event occurs. A DropDownList and a TextBox can trigger a cached event if the AutoPostBack property is set to false.
Validation events :
These events are handled in the page without posting back or caching. The validation server controls use these types of events.
How can you convert a Cached event of control to a postback event?
You can convert a Cached event of control to a postback event by setting the AutoPostBack property to true.
What is the order in which events are executed?
The validations controls are evaluated before the page is posted back to the server. When the page is posted back, the Page_Init and Page_Load events are handled, then cached events are handled, and finally, the event that caused the postback is processed. Among cached events, the event order is determined by the order of the controls on the Web form.
No comments:
Post a Comment