Const Keyword

Const keyword specifies that the value of the field or the local variable cannot be modified

Types supported: byte, char, short, int, long, float, double, decimal, bool and string

A constant expression is an expression that can be fully evaluated at compile time. Therefore, the only possible values for constants of reference types are string and null

Abstract Keyword

Abstract classes have the following features:
Abstract Class can’t have objects
Abstract Class may contain abstract methods and accessors
Use of sealed modifier is not allowed to prevent inheriting abstract class
Non-abstract class dervied from an abstract class must include actual implementations of all inherited abstract methods and accessors
Use abstract modifier to indicate that the method or property does not contain implementation

Abstract Methods have following features:

An abstract method is implicitly a virtual method
Abstract methods can reside only in an abstract class
Since abstract method lacks implementation, there are no braces
Implementation is provided by overriding method residing in a non-abstract class
It is an error to use static/virtual modifiers in in an abstract method

Abstract Properties have following features (similar to Abstract methods except)

It is an error to use the abstract modifier on a static property
Override modifier is used in a derived class to override abstract property

Access Modifiers

Access Modifiers:
Public
Private
Protected
Internal
Protected Internal

Public:
Access is not restricted

Private:
Members of the current class only

Protected:
All members in the current class
Classes derived from this class

Internal:
Access is limited to the current assembly

Protected Internal:
Access is limited to the current assembly
All deriving classes

Notes:
Arranging all the access modifiers per availability
Public > Protected > Internal > Protected Internal > Private

Access modifiers are not allowed on namespaces

ASP.net Page Lifecycle

Object Initialization
Load Viewstate Data
LoadPostData processes PostBack data
Object Load
Raise PostBack change events
Process Client Side PostBack Event
Prerender the Objects
ViewState Saved
Render to HTML
Disposal

PreInit
Check the IsPostBack property
Create/Recreate dynamic controls
Set a master page dynamically
Set the Theme property dynamically
Read or set profile property values

Init
Raised after all controls have been initialized
Raised after all Skin settings have been applied
Used to read or initialize control properties

InitComplete
Raised by Page object
Used for processing tasks that need initialization to be complete

PreLoad
At this event, page loads viewstate for itself and all the controls
Processes any postback data included with the Request instance

Load
Page calls the OnLoad event method on the Page
Then recursively does the same for each child control
Use the OnLoad method to initialize controls and database connections

Control Events
Use this to handle control events like Click, TextChanged

LoadComplete

PreRender
Before this event occurs:
Page object calls EnsureChildControls for each control and for the page
For each data bound control with datasource, databind is called
b. PreRender event occurs for each control on the page

SaveStateComplete
At this stage Viewstate is saved for the page and all the controls
Any changes to the page/control will be ignored
Use this event to perform tasks that require viewstate to be saved

Render
This is not an event
It is a stage of processing when Render method is called for each control
All asp.net server controls have render, that write control markup for the browser

Unload
This event occurs for each control and then for the page
Use this event for final cleanup, such as closing database connections

General Page Life-Cycle Stages

Page Request
Page request occurs before page lifecycle begins
When the page is requested by a user, ASP.net determines whether the page needs to be parsed and compiled or send a cached version

Start
In the start step, page properties such as Request and Response are set
Page also determines whether the request is a postback or a new request
Sets the IsPostBack property
Sets the UI culture

Page Initialization
Controls on the page are available
Each control’s unique ID property is set
Theme is applied
If current page is a postback, the data is not yet loaded
Values are not restored from viewstate

Load
If page is a postback, control properties are loaded
Information from viewstate is recovered

Validation
Validate method of all the controls is called

Postback Event Handling
If page is a postback, eventhandlers are called

Rendering
Before rendering, viewstate is saved for the page and all the controls
During this stage, page calls Render method for all the controls
Providing a text writer to write output to the page’s Response property

Unload
Unload is called when page has finished rendering
Page properties such as Request/Response

Postback

Postback on Client side:

User actions on webforms cause postback
Postback events cause the browser to send page data i.e. Viewstate to the server
Asp.net 1.1 provided postback to a page itself, 2.0 provides cross page postback
Asp.net provides the javascript_doPostBack() function that records the name of the control that caused the postback
This function also places the event arguments in the hidden form fields called _EVENTTARGET and _EVENTARGUMENT

Postback processing on server side:
Postback data is examined by methods of those controls that implement either the IpostBackDataHandler or IpostBackEventHandler
Postback data is examined to find if a client side event was generated, if so corresponding server side event is raised
Custom PostBack can be created by calling the GetPostBackEventReference method