Saturday, March 29, 2014

ASP.NET Page life cycle

This is some of the notes i have collected when digging more details on the page life cycle. The below points are fetched up from all over the net.

Page Life Cycle in ASP.NET

Page_PreInit
  • This is the first event raised in the ASP.NET page life cycle.
  • IsPostBack property would have bee already set by this event, so we can determine whether this is the first request or not.
  • Create or re-create dynamic controls.
  • Set a master page dynamically.
  • Set the Theme property dynamically.
  • Read or set profile property values.
  • We can not access any ViewState and PostBack data, because that data would not be loaded by this time.
  • Master page can only be set in this event or before to this event. if we try to set it in any other event, exception will be thrown.
 There are two ways to add dynamic controls in the page,
  • If there is no master page associated with the current page, then we can create dynamic controls in this event. 
  • If there is a master page associated with the current page, then we need to add controls in the Init event

Page_Init
  • This event is recursive, The Init event of individual controls occurs before the Init event of the page.
  • Create or re-create dynamic controls.
  • By using this event we can read or initialize control properties.
  • We can set the Page.ViewStateUserKey value only in this event,if we try to set it in any other event, exception will be thrown.
  • We can not access any ViewState and PostBack data, because that data would not be loaded by this time.

Page_InitComplete
  • This is the last event in the initialization.
  • Before this event TrackViewState() method would be called. So from here on wards, any changes to viewstate data will be persisted to next postbacks.
  • We can not access any ViewState and PostBack data in this event, because that data would not be loaded by this time.
  • We can use this event to change any data, that should be persisted in the next postback.

Page_PreLoad
  • This is the first event will be called after loading the ViewState and the Postback data by two methods, LoadViewState and LoadPostData respectively.
  • The purpose of the Page.PreLoad event is to provide a hook for control authors. The behavior of the load phase of the page lifecycle, is that  the Load event is raised on the page before it is raised on all its child controls. As a control author, you might want to perform some action after viewstate is loaded (so Init is too early), but before Page_Load is called (so Load is too late). How you do that is to add an event handler to Page.PreLoad.

Page_Load
  • This event is recursive, The Load event of the page occurs before the Load event of the controls.
  • We can use this event to set properties in controls and to 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.

Page_LoadComplete
  • Use this event for tasks that require that all other controls on the page be loaded.
  • There may be certain situations where we need to do some processing after control event, in that case Load event will be too early, so we can use the LoadComplete event for this king of processing.When you hook up several methods to the Load event you don't know the order they will get called. So you have the PreLoad, Load and LoadComplete events to have some more control as to in what order your code gets called. The use of this might not always be clear when working only with your page class. When working with controls however, with the need to have some code running at Load time, you might want to make it run right before or right after what would normally happen in the Load event. Then you can use the PreLoad and LoadComplete methods.

Page_PreRender
  • This event is recursive, The PreRender event of the page occurs before the PreRender event of the controls.
  • Raised after the Page object has created all controls that are required in order to render the page, including child controls of composite controls.
  • Use the event to make final changes to the contents of the page or its controls before the rendering stage begins.
Page_PreRenderComplete
  • Raised after each data bound control whose DataSourceID property is set calls its DataBind method.
  • This is the last event raised before the page's view state is saved.

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.

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.

Unload
  • This event is recursive, The Unload event of individual controls occurs before the Unload event of 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.

Sunday, March 23, 2014

typeof

typeof is an operator, which cannot be overloaded.
Used to obtain the System.Type object for a type.
This operator uses reflection to access the metadata descriptions of the types.
There is only one System.Type object for any given type. This means that for a type T, typeof(T)==typeof(T) is always true. This type cannot be dynamic.

Synatx: typeof(type)
             typeof(unbound-type-name)
             typeof(void)

It returns the System.Type object for the specified type.

[Note: An Unbound-type-name is very similar to a type name except that an unbound-type-name contains generic-dimension-specifiers wherea type-name contains type-argument-lists.]

Examples:
typeof(int);  //System.Int32
typeof(List<int>);  //System.Collections,Generic.List'1[System.Int32]
typefo(Dictionary<,>);  //System.Collections,Generic.Dictionary'2[TKey,TValue]
typeof(void); //System.Void

   The result of typeof(void) is the System.Type object that represents the absence of a type. This special type object is useful in class libraries that allow reflection onto methods in the language, where those methods wish to have a way to represent the return type of any method, including void methods, with an instance of System.Type.

Test:
Employee objEmployee = new Employee();
System.Type t = typeof(objEmployee); //throws error, because typeof only works on types, not on variables.
System.Type t = typeof(Employee) ; //it is fine.