Asp.Net, Sql Server, JavaScript, XML, MVC, Web Services, JQuery, Interview Questions etc.
Wednesday, 31 December 2014
Tuesday, 30 December 2014
Difference between Sql server 2005 and 2008
Sr No | SQL Server 2005 | SQL Server 2008 |
1 | XML datatype is introduced. | XML datatype is used. |
2 | Can not encrypt the entire database. | Can encrypt the entire database introduced in 2008. |
3 | Datetime is used for both date and time. | Date and time are seperately used for date and time |
4 | No table datatype is included. | Table datatype introduced. |
5 | SSIS is started using. | SSIS avails in this version. |
6 | CMS is not available. |
Central Management Server(CMS) is Introduced.
|
7 | PBM is not available |
Policy based management(PBM) server is Introduced.
|
Difference between sqlserver 2008 and sqlserver 2012
Sql server 2012:
1.The SQL Server 2012 uses 48 bit precision for spatial
2.In SQL server 2012 has unlimited concurrent connections
3.By default it supports 15,000 partitions
4.Available new string functions CONCATE and FORMAT
5.Available new conversion functions are PARSE ,TRY_CONVERT,TRY_PARSE
6.Microsoft.SqlServer.Dac and Microsoft.SqlServer.Dac.Extensions are introduced to perform operations on Packages
Sql server 2008:
1.Maximum number concurrent connections to SQL Server 2008 is 32767
2.The SQL Server 2008 uses 27 bit precision for spatial
3.It can support only 1000 partitions
4.The CONCATE and FORMAT not available
5.Not available conversion function which are mentioned in SQL 2012
1.The SQL Server 2012 uses 48 bit precision for spatial
2.In SQL server 2012 has unlimited concurrent connections
3.By default it supports 15,000 partitions
4.Available new string functions CONCATE and FORMAT
5.Available new conversion functions are PARSE ,TRY_CONVERT,TRY_PARSE
6.Microsoft.SqlServer.Dac and Microsoft.SqlServer.Dac.Extensions are introduced to perform operations on Packages
Sql server 2008:
1.Maximum number concurrent connections to SQL Server 2008 is 32767
2.The SQL Server 2008 uses 27 bit precision for spatial
3.It can support only 1000 partitions
4.The CONCATE and FORMAT not available
5.Not available conversion function which are mentioned in SQL 2012
Difference between .NET 3.5 and .NET 4.0
.NET 3.5
|
.NET 4.0
|
|
Definition |
A version of .NET framework that preceded .NET 3.0 |
A version of .NET framework that preceded .NET 3.5 |
Direct Access to Client Data |
No |
Yes, using client data view and client data context objects |
View State can be applied to the Control level |
No |
Yes, by using viewstate mechanism. |
Permanent URL redirection |
No |
Yes, by using RedirectPermanent() |
Size of installer |
2.7 MB |
869 KB |
Enhanced features compared to previous versions |
ASP.NET AJAX, Language Integrated Query (LINQ), enhanced Window Communication Foundation. |
Improvements in CLR , BCL, data modeling, parallel programming, asp.net enhancements etc. |
Output Caching |
Yes, with limitation |
Yes, easy to configure one or more custom output-cache providers. |
Size of Web config file |
Large due the Ajax, routing and integration with IIIS 7. |
Can be empty or small as major configuration elements have been moved to the machine.config file. |
Setting of Meta Tags |
Two meta tags can be used-
|
The keywords and meta tags can be included as part of page directive itself. |
A control to filter the data returns by EntitiyDataSource and LinqDataSource controls |
Not present |
Yes. QueryExtender Control |
Hashing Algorithm |
HMACSHA1 |
HMACSHA256 |
Asp.Net Page Life Cycle
INTRODUCTION :
Using Visual Studio, the development tool can develop very compelling
applications using ASP.NET, with the ease of drag-and-drop server
controls. Latest version finally announced by Microsoft. By adopting
agile practices, and using IDE and ALM tools, Microsoft have been able
to complete the release in half as many milestones this time around.
Developing great apps for Windows 8 is an important goal of this
release.
ASP.NET is the next generation web application framework developed and
marketed by Microsoft based on .NET Framework. But not to be confused
that it's not an upgraded version of ASP. It was first released in
January 2002 with version 1.0 of the .NET Framework, and is the
successful successor to Microsoft's Active Server Pages (ASP)
technology.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
HOW IT WORKS? :
Developing applications are easy unless you are familiar with the page
life cycle process in order to correctly initialize controls. The life
cycle of a control is based on the page life cycle, and the page raises
many of the events that you need to handle in a custom control.
When a web browser requests a page from a web server, the web server
will first check if the request is for an HTML page. If it is, the
request is fulfilled by fetching the files from the OS and then
returning it to the client (web browser). If the client is requesting an
ASP.NET page, IIS will pass the request to the Asp.Net runtime, which
will then process the application by reads the file, line by line, and
executes the scripts in the file. After process complete it returns the
output to the client as an format of pure html.
When an ASP.NET page runs, the page goes through a life cycle in which
it performs a series of processing steps. These include initialization,
instantiating controls, restoring and maintaining state, running event
handler code, and rendering. It is important for you to understand the
page life cycle so that you can write code at the appropriate life-cycle
stage for the effect you intend.
In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as
S = Start
I = Initialization
L = Load
V = Validate
E = Event Handlers
R = Render
Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:
PAGE REQUEST:
The page request occurs before the page life cycle begins. When the page
is requested by a user, ASP.NET determines whether the page needs to be
parsed and compiled, or whether a cached version of the page can be
sent in response without running the page.
START:
In the start stage, page properties such as Request and Response are
set. At this stage, the page also determines whether the request is a
postback or a new request and sets the IsPostBack property. The page
also sets the UICulture property.
INITIALIZATION:
During page initialization, controls on the page are available and each
control's UniqueID property is set. A master page and themes are also
applied to the page if applicable. If the current request is a postback,
the postback data has not yet been loaded and control property values
have not been restored to the values from view state.
LOAD:
During load, if the current request is a postback, control properties
are loaded with information recovered from view state and control state.
VALIDATE & EVENT HANDLING:
If the request is a postback, control event handlers are called. After
that, the Validate method of all validator controls is called, which
sets the IsValid property of individual validator controls and of the
page. There is an exception to this sequence: the handler for the event
that caused validation is called after validation.
RENDER:
Before rendering, view state is saved for the page and all controls.
During the rendering stage, the page calls the Render method for each
control, providing a text writer that writes its output to the
OutputStream object of the page's Response property.
UNLOAD:
The Unload event is raised after the page has been fully rendered, sent
to the client, and is ready to be discarded. At this point, page
properties such as Response and Request are unloaded and cleanup is
performed.
Within each stage of the life cycle of a page, the page raises events
that you can handle to run your own code. For control events, you bind
the event handler to the event, either declaratively using attributes
such as onclick, or in code. Pages also support automatic event wire-up,
meaning that ASP.NET looks for methods with particular names and
automatically runs those methods when certain events are raised. If the
AutoEventWireup attribute of the @ Page directive is set to true, page
events are automatically bound to methods that use the naming convention
of Page_event, such as Page_Load and Page_Init.
PreInit:
Raised after the start stage is complete and before the initialization stage begins. Use this event for the following:
- Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
- Create or re-create dynamic controls.
- Set a master page dynamically.
- Set the Theme property dynamically.
- Read or set profile property values.
If the request is a postback, the values of the controls have not yet
been restored from view state. If you set a control property at this
stage, its value might be overwritten in the next event.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
protected void Page_PreInit(object sender, EventArgs e)
{
/* Use this event for the following:
Check the IsPostBack property to determine whether
this is the first time the page is being
processed.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.*/
}
}
Init:
Raised after all controls have been initialized and any skin settings
have been applied. The Init event of individual controls occurs before
the Init event of the page. Use this event to read or initialize control
properties.
InitComplete:
protected void Page_Init(object sender, EventArgs e)
{
/* Raised after all controls have been initialized and any skin
settings have been applied. Use this event to read or initialize control
properties. */
}
InitComplete:
Raised at the end of the page's initialization stage. Only one operation
takes place between the Init and InitComplete events: tracking of view
state changes is turned on. View state tracking enables controls to
persist any values that are programmatically added to the ViewState
collection. Until view state tracking is turned on, any values added to
view state are lost across postbacks. Controls typically turn on view
state tracking immediately after they raise their Init event. Use this
event to make changes to view state that you want to make sure are
persisted after the next postback.
protected void Page_InitComplete(object sender, EventArgs e)
{
/* Raised by the Page object. Use this event for processing tasks that require all initialization be complete. */
}
PreLoad:
Raised after the page loads view state for itself and all controls, and
after it processes postback data that is included with the Request
instance.
protected override void OnPreLoad(EventArgs e)
{
/* Use this event if you need to perform processing on your page or control before the Load event. //
Before the Page instance raises this event, it loads view state for
itself and all controls, and then processes any postback data included
with the Request instance.*/
}
Load:
The Page object calls the OnLoad method on the Page object, and then
recursively does the same for each child control until the page and all
controls are loaded. The Load event of individual controls occurs after
the Load event of the page. Use the OnLoad event method to set
properties in controls and to establish database connections.
protected void Page_Load(object sender, EventArgs e)
{
/*
The Page calls the OnLoad event method on the Page, then recursively
does the same for each child control, which does the same for each of
its child controls until the page and all controls are loaded. Use the
OnLoad event method to set properties in controls and establish database
connections.*/
}
Control Events:
Use these events to handle specific control events, such as a Button
control's Click event or a TextBox control's TextChanged event. In a
postback request, if the page contains validator controls, check the
IsValid property of the Page and of individual validation controls
before performing any processing.
protected void Button1_Click(object sender, EventArgs e)
{
/* This is just an example of control event. Here it is button click event that caused the postback. */
}
Load Complete:
Raised at the end of the event-handling stage. Use this event for tasks
that require that all other controls on the page be loaded.
protected void Page_LoadComplete(object sender, EventArgs e)
{
/* Use this event for tasks that require that all other controls on the page be loaded.*/
}
PreRender:
Raised after the Page object has created all controls that are required
in order to render the page, including child controls of composite
controls. The Page object raises the PreRender event on the Page object,
and then recursively does the same for each child control. The
PreRender event of individual controls occurs after the PreRender event
of the page. Use the event to make final changes to the contents of the
page or its controls before the rendering stage begins.
protected override void OnPreRender(EventArgs e)
{
/* Each data bound control whose DataSourceID property is set calls its DataBind method. The
PreRender event occurs for each control on the page. Use the event to
make final changes to the contents of the page or its controls.*/
}
PreRenderComplete:
Raised after each data bound control whose DataSourceID property is set calls its DataBind method.
SaveStateComplete:
Raised after view state and control state have been saved for the page
and for all controls. Any changes to the page or controls at this point
affect rendering, but the changes will not be retrieved on the next
postback.
protected override void OnSaveStateComplete(EventArgs e)
{
/*
Before this event occurs, ViewState has been saved for the page and
for all controls. Any changes to the page or controls at this point will
be ignored. // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/
}
Render:
This is not an event; instead, at this stage of processing, the Page
object calls this method on each control. All ASP.NET Web server
controls have a Render method that writes out the control's markup to
send to the browser. If you create a custom control, you typically
override this method to output the control's markup. However, if your
custom control incorporates only standard ASP.NET Web server controls
and no custom markup, you do not need to override the Render method. A
user control automatically incorporates rendering, so you do not need to
explicitly render the control in code.
Unload:
Raised for each control and then for the page. In controls, use this
event to do final cleanup for specific controls, such as closing
control-specific database connections. For the page itself, use this
event to do final cleanup work, such as closing open files and database
connections, or finishing up logging or other request-specific tasks.
During the unload stage, the page and its controls have been rendered,
so you cannot make further changes to the response stream. If you
attempt to call a method such as the Response.Write method, the page
will throw an exception.
protected void Page_UnLoad(object sender, EventArgs e)
{
/*
This event occurs for each control and then for the page. In controls,
use this event to do final cleanup for specific controls, such as
closing control-specific database connections. During the unload stage,
the page and its controls have been rendered, so you cannot make further
changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/
}
Individual ASP.NET server controls have their own life cycle that is
similar to the page life cycle. For example, a control's Init and Load
events occur during the corresponding page events. Although both Init
and Load recursively occur on each control, they happen in reverse
order. The Init event (and also the Unload event) for each child control
occur before the corresponding event is raised for its container
(bottom-up). However the Load event for a container occurs before the
Load events for its child controls (top-down). Master pages behave like
child controls on a page: the master page Init event occurs before the
page Init and Load events, and the master page Load event occurs after
the page Init and Load events.
If controls are created dynamically at run time or declaratively within
templates of data-bound controls, their events are initially not
synchronized with those of other controls on the page. For example, for a
control that is added at run time, the Init and Load events might occur
much later in the page life cycle than the same events for controls
created declaratively. Therefore, from the time that they are
instantiated, dynamically added controls and controls in templates raise
their events one after the other until they have caught up to the event
during which it was added to the Controls collection.
DataBinding:
Raised after the control's PreRender event, which occurs after the
page's PreRender event. This applies to controls whose DataSourceID
property is set declaratively. Otherwise the event happens when you call
the control's DataBind method. This event marks the beginning of the
process that binds the control to the data. Use this event to manually
open database connections, if required, and to set parameter values
dynamically before a query is run.
RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
Raised after the control's DataBinding event. Use this event to
manipulate content that is not dependent on data binding. For example,
at run time, you might programmatically add formatting to a header or
footer row in a GridView control.
RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
Raised after the control's RowCreated or ItemCreated event. When this
event occurs, data is available in the row or item, so you can format
data or set the FilterExpression property on child data source controls
in order to display related data within the row or item.
DataBound:
Raised at the end of data-binding operations in a data-bound control. In
a GridView control, data binding is complete for all rows and any child
controls. Use this event to format data-bound content or to initiate
data binding in other controls that depend on values from the current
control's content.
The Login control can use settings in the Web.config file to manage
membership authentication automatically. However, if your application
requires you to customize how the control works, or if you want to
understand how Login control events relate to the page life cycle.
LoggingIn:
Raised during a postback, after the page's LoadComplete event has
occurred. This event marks the beginning of the login process. Use this
event for tasks that must occur prior to beginning the authentication
process.
Authenticate:
Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.
LoggedIn:
Raised after the user name and password have been authenticated. Use
this event to redirect to another page or to dynamically set the text in
the control. This event does not occur if there is an error or if
authentication fails.
LoginError:
Raised if authentication was not successful. Use this event to set text
in the control that explains the problem or to direct the user to a
different page.
Monday, 29 December 2014
Asp.Net Page Life Cycle
INTRODUCTION :
Using Visual Studio, the development tool can develop very compelling
applications using ASP.NET, with the ease of drag-and-drop server
controls. Latest version finally announced by Microsoft. By adopting
agile practices, and using IDE and ALM tools, Microsoft have been able
to complete the release in half as many milestones this time around.
Developing great apps for Windows 8 is an important goal of this
release.
ASP.NET is the next generation web application framework developed and
marketed by Microsoft based on .NET Framework. But not to be confused
that it's not an upgraded version of ASP. It was first released in
January 2002 with version 1.0 of the .NET Framework, and is the
successful successor to Microsoft's Active Server Pages (ASP)
technology.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
HOW IT WORKS? :
Developing applications are easy unless you are familiar with the page
life cycle process in order to correctly initialize controls. The life
cycle of a control is based on the page life cycle, and the page raises
many of the events that you need to handle in a custom control.
When a web browser requests a page from a web server, the web server
will first check if the request is for an HTML page. If it is, the
request is fulfilled by fetching the files from the OS and then
returning it to the client (web browser). If the client is requesting an
ASP.NET page, IIS will pass the request to the Asp.Net runtime, which
will then process the application by reads the file, line by line, and
executes the scripts in the file. After process complete it returns the
output to the client as an format of pure html.
When an ASP.NET page runs, the page goes through a life cycle in which
it performs a series of processing steps. These include initialization,
instantiating controls, restoring and maintaining state, running event
handler code, and rendering. It is important for you to understand the
page life cycle so that you can write code at the appropriate life-cycle
stage for the effect you intend.
In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as
S = Start
I = Initialization
L = Load
V = Validate
E = Event Handlers
R = Render
Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:
PAGE REQUEST:
The page request occurs before the page life cycle begins. When the page
is requested by a user, ASP.NET determines whether the page needs to be
parsed and compiled, or whether a cached version of the page can be
sent in response without running the page.
START:
In the start stage, page properties such as Request and Response are
set. At this stage, the page also determines whether the request is a
postback or a new request and sets the IsPostBack property. The page
also sets the UICulture property.
INITIALIZATION:
During page initialization, controls on the page are available and each
control's UniqueID property is set. A master page and themes are also
applied to the page if applicable. If the current request is a postback,
the postback data has not yet been loaded and control property values
have not been restored to the values from view state.
LOAD:
During load, if the current request is a postback, control properties
are loaded with information recovered from view state and control state.
VALIDATE & EVENT HANDLING:
If the request is a postback, control event handlers are called. After
that, the Validate method of all validator controls is called, which
sets the IsValid property of individual validator controls and of the
page. There is an exception to this sequence: the handler for the event
that caused validation is called after validation.
RENDER:
Before rendering, view state is saved for the page and all controls.
During the rendering stage, the page calls the Render method for each
control, providing a text writer that writes its output to the
OutputStream object of the page's Response property.
UNLOAD:
The Unload event is raised after the page has been fully rendered, sent
to the client, and is ready to be discarded. At this point, page
properties such as Response and Request are unloaded and cleanup is
performed.
Within each stage of the life cycle of a page, the page raises events
that you can handle to run your own code. For control events, you bind
the event handler to the event, either declaratively using attributes
such as onclick, or in code. Pages also support automatic event wire-up,
meaning that ASP.NET looks for methods with particular names and
automatically runs those methods when certain events are raised. If the
AutoEventWireup attribute of the @ Page directive is set to true, page
events are automatically bound to methods that use the naming convention
of Page_event, such as Page_Load and Page_Init.
PreInit:
Raised after the start stage is complete and before the initialization stage begins. Use this event for the following:
- Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
- Create or re-create dynamic controls.
- Set a master page dynamically.
- Set the Theme property dynamically.
- Read or set profile property values.
If the request is a postback, the values of the controls have not yet
been restored from view state. If you set a control property at this
stage, its value might be overwritten in the next event.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
protected void Page_PreInit(object sender, EventArgs e)
{
/* Use this event for the following:
Check the IsPostBack property to determine whether
this is the first time the page is being
processed.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.*/
}
}
Init:
Raised after all controls have been initialized and any skin settings
have been applied. The Init event of individual controls occurs before
the Init event of the page. Use this event to read or initialize control
properties.
InitComplete:
protected void Page_Init(object sender, EventArgs e)
{
/* Raised after all controls have been initialized and any skin
settings have been applied. Use this event to read or initialize control
properties. */
}
InitComplete:
Raised at the end of the page's initialization stage. Only one operation
takes place between the Init and InitComplete events: tracking of view
state changes is turned on. View state tracking enables controls to
persist any values that are programmatically added to the ViewState
collection. Until view state tracking is turned on, any values added to
view state are lost across postbacks. Controls typically turn on view
state tracking immediately after they raise their Init event. Use this
event to make changes to view state that you want to make sure are
persisted after the next postback.
protected void Page_InitComplete(object sender, EventArgs e)
{
/* Raised by the Page object. Use this event for processing tasks that require all initialization be complete. */
}
PreLoad:
Raised after the page loads view state for itself and all controls, and
after it processes postback data that is included with the Request
instance.
protected override void OnPreLoad(EventArgs e)
{
/* Use this event if you need to perform processing on your page or control before the Load event. //
Before the Page instance raises this event, it loads view state for
itself and all controls, and then processes any postback data included
with the Request instance.*/
}
Load:
The Page object calls the OnLoad method on the Page object, and then
recursively does the same for each child control until the page and all
controls are loaded. The Load event of individual controls occurs after
the Load event of the page. Use the OnLoad event method to set
properties in controls and to establish database connections.
protected void Page_Load(object sender, EventArgs e)
{
/*
The Page calls the OnLoad event method on the Page, then recursively
does the same for each child control, which does the same for each of
its child controls until the page and all controls are loaded. Use the
OnLoad event method to set properties in controls and establish database
connections.*/
}
Control Events:
Use these events to handle specific control events, such as a Button
control's Click event or a TextBox control's TextChanged event. In a
postback request, if the page contains validator controls, check the
IsValid property of the Page and of individual validation controls
before performing any processing.
protected void Button1_Click(object sender, EventArgs e)
{
/* This is just an example of control event. Here it is button click event that caused the postback. */
}
Load Complete:
Raised at the end of the event-handling stage. Use this event for tasks
that require that all other controls on the page be loaded.
protected void Page_LoadComplete(object sender, EventArgs e)
{
/* Use this event for tasks that require that all other controls on the page be loaded.*/
}
PreRender:
Raised after the Page object has created all controls that are required
in order to render the page, including child controls of composite
controls. The Page object raises the PreRender event on the Page object,
and then recursively does the same for each child control. The
PreRender event of individual controls occurs after the PreRender event
of the page. Use the event to make final changes to the contents of the
page or its controls before the rendering stage begins.
protected override void OnPreRender(EventArgs e)
{
/* Each data bound control whose DataSourceID property is set calls its DataBind method. The
PreRender event occurs for each control on the page. Use the event to
make final changes to the contents of the page or its controls.*/
}
PreRenderComplete:
Raised after each data bound control whose DataSourceID property is set calls its DataBind method.
SaveStateComplete:
Raised after view state and control state have been saved for the page
and for all controls. Any changes to the page or controls at this point
affect rendering, but the changes will not be retrieved on the next
postback.
protected override void OnSaveStateComplete(EventArgs e)
{
/*
Before this event occurs, ViewState has been saved for the page and
for all controls. Any changes to the page or controls at this point will
be ignored. // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/
}
Render:
This is not an event; instead, at this stage of processing, the Page
object calls this method on each control. All ASP.NET Web server
controls have a Render method that writes out the control's markup to
send to the browser. If you create a custom control, you typically
override this method to output the control's markup. However, if your
custom control incorporates only standard ASP.NET Web server controls
and no custom markup, you do not need to override the Render method. A
user control automatically incorporates rendering, so you do not need to
explicitly render the control in code.
Unload:
Raised for each control and then for the page. In controls, use this
event to do final cleanup for specific controls, such as closing
control-specific database connections. For the page itself, use this
event to do final cleanup work, such as closing open files and database
connections, or finishing up logging or other request-specific tasks.
During the unload stage, the page and its controls have been rendered,
so you cannot make further changes to the response stream. If you
attempt to call a method such as the Response.Write method, the page
will throw an exception.
protected void Page_UnLoad(object sender, EventArgs e)
{
/*
This event occurs for each control and then for the page. In controls,
use this event to do final cleanup for specific controls, such as
closing control-specific database connections. During the unload stage,
the page and its controls have been rendered, so you cannot make further
changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/
}
Individual ASP.NET server controls have their own life cycle that is
similar to the page life cycle. For example, a control's Init and Load
events occur during the corresponding page events. Although both Init
and Load recursively occur on each control, they happen in reverse
order. The Init event (and also the Unload event) for each child control
occur before the corresponding event is raised for its container
(bottom-up). However the Load event for a container occurs before the
Load events for its child controls (top-down). Master pages behave like
child controls on a page: the master page Init event occurs before the
page Init and Load events, and the master page Load event occurs after
the page Init and Load events.
If controls are created dynamically at run time or declaratively within
templates of data-bound controls, their events are initially not
synchronized with those of other controls on the page. For example, for a
control that is added at run time, the Init and Load events might occur
much later in the page life cycle than the same events for controls
created declaratively. Therefore, from the time that they are
instantiated, dynamically added controls and controls in templates raise
their events one after the other until they have caught up to the event
during which it was added to the Controls collection.
DataBinding:
Raised after the control's PreRender event, which occurs after the
page's PreRender event. This applies to controls whose DataSourceID
property is set declaratively. Otherwise the event happens when you call
the control's DataBind method. This event marks the beginning of the
process that binds the control to the data. Use this event to manually
open database connections, if required, and to set parameter values
dynamically before a query is run.
RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
Raised after the control's DataBinding event. Use this event to
manipulate content that is not dependent on data binding. For example,
at run time, you might programmatically add formatting to a header or
footer row in a GridView control.
RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
Raised after the control's RowCreated or ItemCreated event. When this
event occurs, data is available in the row or item, so you can format
data or set the FilterExpression property on child data source controls
in order to display related data within the row or item.
DataBound:
Raised at the end of data-binding operations in a data-bound control. In
a GridView control, data binding is complete for all rows and any child
controls. Use this event to format data-bound content or to initiate
data binding in other controls that depend on values from the current
control's content.
The Login control can use settings in the Web.config file to manage
membership authentication automatically. However, if your application
requires you to customize how the control works, or if you want to
understand how Login control events relate to the page life cycle.
LoggingIn:
Raised during a postback, after the page's LoadComplete event has
occurred. This event marks the beginning of the login process. Use this
event for tasks that must occur prior to beginning the authentication
process.
Authenticate:
Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.
LoggedIn:
Raised after the user name and password have been authenticated. Use
this event to redirect to another page or to dynamically set the text in
the control. This event does not occur if there is an error or if
authentication fails.
LoginError:
Raised if authentication was not successful. Use this event to set text
in the control that explains the problem or to direct the user to a
different page.
Asp.Net Page Life Cycle
INTRODUCTION :
Using Visual Studio, the development tool can develop very compelling
applications using ASP.NET, with the ease of drag-and-drop server
controls. Latest version finally announced by Microsoft. By adopting
agile practices, and using IDE and ALM tools, Microsoft have been able
to complete the release in half as many milestones this time around.
Developing great apps for Windows 8 is an important goal of this
release.
ASP.NET is the next generation web application framework developed and
marketed by Microsoft based on .NET Framework. But not to be confused
that it's not an upgraded version of ASP. It was first released in
January 2002 with version 1.0 of the .NET Framework, and is the
successful successor to Microsoft's Active Server Pages (ASP)
technology.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
ASP.NET allow programmers to build dynamic web sites, web applications ,web services and so many strong features. One of the key features of ASP.NET is that it uses an event-based programming model.
HOW IT WORKS? :
Developing applications are easy unless you are familiar with the page
life cycle process in order to correctly initialize controls. The life
cycle of a control is based on the page life cycle, and the page raises
many of the events that you need to handle in a custom control.
When a web browser requests a page from a web server, the web server
will first check if the request is for an HTML page. If it is, the
request is fulfilled by fetching the files from the OS and then
returning it to the client (web browser). If the client is requesting an
ASP.NET page, IIS will pass the request to the Asp.Net runtime, which
will then process the application by reads the file, line by line, and
executes the scripts in the file. After process complete it returns the
output to the client as an format of pure html.
When an ASP.NET page runs, the page goes through a life cycle in which
it performs a series of processing steps. These include initialization,
instantiating controls, restoring and maintaining state, running event
handler code, and rendering. It is important for you to understand the
page life cycle so that you can write code at the appropriate life-cycle
stage for the effect you intend.
In order to memorize whole page life cycle process of Asp.net, keep store this word "SILVER" in your memory, which is defined as
S = Start
I = Initialization
L = Load
V = Validate
E = Event Handlers
R = Render
Before and after "SILVER" there's one step each to be processed. Each step will be completely defined as:
PAGE REQUEST:
The page request occurs before the page life cycle begins. When the page
is requested by a user, ASP.NET determines whether the page needs to be
parsed and compiled, or whether a cached version of the page can be
sent in response without running the page.
START:
In the start stage, page properties such as Request and Response are
set. At this stage, the page also determines whether the request is a
postback or a new request and sets the IsPostBack property. The page
also sets the UICulture property.
INITIALIZATION:
During page initialization, controls on the page are available and each
control's UniqueID property is set. A master page and themes are also
applied to the page if applicable. If the current request is a postback,
the postback data has not yet been loaded and control property values
have not been restored to the values from view state.
LOAD:
During load, if the current request is a postback, control properties
are loaded with information recovered from view state and control state.
VALIDATE & EVENT HANDLING:
If the request is a postback, control event handlers are called. After
that, the Validate method of all validator controls is called, which
sets the IsValid property of individual validator controls and of the
page. There is an exception to this sequence: the handler for the event
that caused validation is called after validation.
RENDER:
Before rendering, view state is saved for the page and all controls.
During the rendering stage, the page calls the Render method for each
control, providing a text writer that writes its output to the
OutputStream object of the page's Response property.
UNLOAD:
The Unload event is raised after the page has been fully rendered, sent
to the client, and is ready to be discarded. At this point, page
properties such as Response and Request are unloaded and cleanup is
performed.
Within each stage of the life cycle of a page, the page raises events
that you can handle to run your own code. For control events, you bind
the event handler to the event, either declaratively using attributes
such as onclick, or in code. Pages also support automatic event wire-up,
meaning that ASP.NET looks for methods with particular names and
automatically runs those methods when certain events are raised. If the
AutoEventWireup attribute of the @ Page directive is set to true, page
events are automatically bound to methods that use the naming convention
of Page_event, such as Page_Load and Page_Init.
PreInit:
Raised after the start stage is complete and before the initialization stage begins. Use this event for the following:
- Check the IsPostBack property to determine whether this is the first time the page is being processed. The IsCallback and IsCrossPagePostBack properties have also been set at this time.
- Create or re-create dynamic controls.
- Set a master page dynamically.
- Set the Theme property dynamically.
- Read or set profile property values.
If the request is a postback, the values of the controls have not yet
been restored from view state. If you set a control property at this
stage, its value might be overwritten in the next event.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
protected void Page_PreInit(object sender, EventArgs e)
{
/* Use this event for the following:
Check the IsPostBack property to determine whether
this is the first time the page is being
processed.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.*/
}
}
Init:
Raised after all controls have been initialized and any skin settings
have been applied. The Init event of individual controls occurs before
the Init event of the page. Use this event to read or initialize control
properties.
InitComplete:
protected void Page_Init(object sender, EventArgs e)
{
/* Raised after all controls have been initialized and any skin
settings have been applied. Use this event to read or initialize control
properties. */
}
InitComplete:
Raised at the end of the page's initialization stage. Only one operation
takes place between the Init and InitComplete events: tracking of view
state changes is turned on. View state tracking enables controls to
persist any values that are programmatically added to the ViewState
collection. Until view state tracking is turned on, any values added to
view state are lost across postbacks. Controls typically turn on view
state tracking immediately after they raise their Init event. Use this
event to make changes to view state that you want to make sure are
persisted after the next postback.
protected void Page_InitComplete(object sender, EventArgs e)
{
/* Raised by the Page object. Use this event for processing tasks that require all initialization be complete. */
}
PreLoad:
Raised after the page loads view state for itself and all controls, and
after it processes postback data that is included with the Request
instance.
protected override void OnPreLoad(EventArgs e)
{
/* Use this event if you need to perform processing on your page or control before the Load event. //
Before the Page instance raises this event, it loads view state for
itself and all controls, and then processes any postback data included
with the Request instance.*/
}
Load:
The Page object calls the OnLoad method on the Page object, and then
recursively does the same for each child control until the page and all
controls are loaded. The Load event of individual controls occurs after
the Load event of the page. Use the OnLoad event method to set
properties in controls and to establish database connections.
protected void Page_Load(object sender, EventArgs e)
{
/*
The Page calls the OnLoad event method on the Page, then recursively
does the same for each child control, which does the same for each of
its child controls until the page and all controls are loaded. Use the
OnLoad event method to set properties in controls and establish database
connections.*/
}
Control Events:
Use these events to handle specific control events, such as a Button
control's Click event or a TextBox control's TextChanged event. In a
postback request, if the page contains validator controls, check the
IsValid property of the Page and of individual validation controls
before performing any processing.
protected void Button1_Click(object sender, EventArgs e)
{
/* This is just an example of control event. Here it is button click event that caused the postback. */
}
Load Complete:
Raised at the end of the event-handling stage. Use this event for tasks
that require that all other controls on the page be loaded.
protected void Page_LoadComplete(object sender, EventArgs e)
{
/* Use this event for tasks that require that all other controls on the page be loaded.*/
}
PreRender:
Raised after the Page object has created all controls that are required
in order to render the page, including child controls of composite
controls. The Page object raises the PreRender event on the Page object,
and then recursively does the same for each child control. The
PreRender event of individual controls occurs after the PreRender event
of the page. Use the event to make final changes to the contents of the
page or its controls before the rendering stage begins.
protected override void OnPreRender(EventArgs e)
{
/* Each data bound control whose DataSourceID property is set calls its DataBind method. The
PreRender event occurs for each control on the page. Use the event to
make final changes to the contents of the page or its controls.*/
}
PreRenderComplete:
Raised after each data bound control whose DataSourceID property is set calls its DataBind method.
SaveStateComplete:
Raised after view state and control state have been saved for the page
and for all controls. Any changes to the page or controls at this point
affect rendering, but the changes will not be retrieved on the next
postback.
protected override void OnSaveStateComplete(EventArgs e)
{
/*
Before this event occurs, ViewState has been saved for the page and
for all controls. Any changes to the page or controls at this point will
be ignored. // Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.*/
}
Render:
This is not an event; instead, at this stage of processing, the Page
object calls this method on each control. All ASP.NET Web server
controls have a Render method that writes out the control's markup to
send to the browser. If you create a custom control, you typically
override this method to output the control's markup. However, if your
custom control incorporates only standard ASP.NET Web server controls
and no custom markup, you do not need to override the Render method. A
user control automatically incorporates rendering, so you do not need to
explicitly render the control in code.
Unload:
Raised for each control and then for the page. In controls, use this
event to do final cleanup for specific controls, such as closing
control-specific database connections. For the page itself, use this
event to do final cleanup work, such as closing open files and database
connections, or finishing up logging or other request-specific tasks.
During the unload stage, the page and its controls have been rendered,
so you cannot make further changes to the response stream. If you
attempt to call a method such as the Response.Write method, the page
will throw an exception.
protected void Page_UnLoad(object sender, EventArgs e)
{
/*
This event occurs for each control and then for the page. In controls,
use this event to do final cleanup for specific controls, such as
closing control-specific database connections. During the unload stage,
the page and its controls have been rendered, so you cannot make further
changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception.*/
}
Individual ASP.NET server controls have their own life cycle that is
similar to the page life cycle. For example, a control's Init and Load
events occur during the corresponding page events. Although both Init
and Load recursively occur on each control, they happen in reverse
order. The Init event (and also the Unload event) for each child control
occur before the corresponding event is raised for its container
(bottom-up). However the Load event for a container occurs before the
Load events for its child controls (top-down). Master pages behave like
child controls on a page: the master page Init event occurs before the
page Init and Load events, and the master page Load event occurs after
the page Init and Load events.
If controls are created dynamically at run time or declaratively within
templates of data-bound controls, their events are initially not
synchronized with those of other controls on the page. For example, for a
control that is added at run time, the Init and Load events might occur
much later in the page life cycle than the same events for controls
created declaratively. Therefore, from the time that they are
instantiated, dynamically added controls and controls in templates raise
their events one after the other until they have caught up to the event
during which it was added to the Controls collection.
DataBinding:
Raised after the control's PreRender event, which occurs after the
page's PreRender event. This applies to controls whose DataSourceID
property is set declaratively. Otherwise the event happens when you call
the control's DataBind method. This event marks the beginning of the
process that binds the control to the data. Use this event to manually
open database connections, if required, and to set parameter values
dynamically before a query is run.
RowCreated (GridView only) or
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
ItemCreated (DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater, and ListView controls) :
Raised after the control's DataBinding event. Use this event to
manipulate content that is not dependent on data binding. For example,
at run time, you might programmatically add formatting to a header or
footer row in a GridView control.
RowDataBound (GridView only) or
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
ItemDataBound (DataList, SiteMapPath, DataGrid, Repeater, and ListView controls) :
Raised after the control's RowCreated or ItemCreated event. When this
event occurs, data is available in the row or item, so you can format
data or set the FilterExpression property on child data source controls
in order to display related data within the row or item.
DataBound:
Raised at the end of data-binding operations in a data-bound control. In
a GridView control, data binding is complete for all rows and any child
controls. Use this event to format data-bound content or to initiate
data binding in other controls that depend on values from the current
control's content.
The Login control can use settings in the Web.config file to manage
membership authentication automatically. However, if your application
requires you to customize how the control works, or if you want to
understand how Login control events relate to the page life cycle.
LoggingIn:
Raised during a postback, after the page's LoadComplete event has
occurred. This event marks the beginning of the login process. Use this
event for tasks that must occur prior to beginning the authentication
process.
Authenticate:
Raised after the LoggingIn event. Use this event to override or enhance the default authentication behavior of a Login control.
LoggedIn:
Raised after the user name and password have been authenticated. Use
this event to redirect to another page or to dynamically set the text in
the control. This event does not occur if there is an error or if
authentication fails.
LoginError:
Raised if authentication was not successful. Use this event to set text
in the control that explains the problem or to direct the user to a
different page.
Subscribe to:
Posts (Atom)