what is Page_Init Use?

In most of code behind pages of sample applications I see the constructor with page_int initializer
e.g. web page is ProjectEntry.aspx then in ProjectEntry.aspx.cs
public ProjectEntry()
{
Page.Init += new System.EventHandler(Page_Init);
}
private void Page_Init(object sender, EventArgs e)
{
InitializeComponent();
}

What is its use and its advantage ?
is it a good practice or bad to use it
This will explain it better than I can and it is from this link. Hope this helps.
http://blog.daveranck.com

ASP.Net 1.x Page Lifecycle

I thought I would put together some quick notes om ASP.Net 1.x Page Execution Lifecycle. There have been many posts on this before and the data here was originally taken from a list on ASPAlliance found here:http://authors.aspalliance.com/aldotnet/examples/plediagram.htm . First here's the list and next I'll comment on a few of the events and how to leverage them.

Use the following key for the events below:
Black - every time page is processed
Red - only if the request is transacted
Green - only on postback
Blue - only if tracing is enabled

Begin Transaction (only when transactions are enabled for the page)
	Begin Transaction	ProcessRequestTransacted()
		TransactedCallback() on ------- Process Request Main ------- (described below) Transactions.InvokeTransacted -- parts of the request that need to be done under transacted context
Process Request Main (every page, this is the main execution path)
	Init	InitRecursive() Raise OnInit (recursive) Begin tracking viewstate
	LoadViewState	LoadPageViewState() LoadPageStateFromPersistenceMedium()
	ProcessPostData1	ProcessPostData(_requestValueCollection, true /* BeforeLoad */); Hand postback data to the controls that exist before Page_Load Page.Validate()
	Load	LoadRecursive(); Fire OnLoad() (recursive)
	ProcessPostData2	ProcessPostData(_leftoverPostData, false /* BeforeLoad */); Hand postback data to controls added in Load (using LoadControl, for example)
	Raise ChangedEvents	RaiseChangedEvents() RaisePostDataChangedEvent() on each control with postback data that is not an IPostBackEventHandler
	Raise PostBackEvent	RaisePostBackEvent(_requestValueCollection) RaisePostBackEvent() on the control that caused the postback
	PreRender	PreRenderRecursive() if Page.Visible EnsureChildControls() -- creates controls if they haven't already been created by databinding Fire OnPreRender (recursive)
	Build Trace Tree	BuildProfileTree("ROOT", EnableViewState)
	SaveViewState	SavePageViewState() Save state recursively for the page and it's controls
	Render	RenderControl(CreateHtmlTextWriter(Response.Output)) if Page.Visible Render() (recursive)
Finish Transaction (only when transactions are enabled for the page)
	End Transaction	Fire OnAbortTransaction() or OnCommitTransaction()
End Trace (only when Tracing is enabled)
	Trace.EndRequest	if PageOutput Trace.Render
Process Request Cleanup (every request) * Set Request and Response to null
	UnloadRecursive	UnloadRecursive() Fire OnUnload() (recursive) Dispose()

First, Page Init executes (I'm going to leave out the transaction-related events - you do create a DAL for your data access code, don't you ;-) ). One good use for this event is for wiring up event handlers. Just be aware that viewstate has not yet loaded.

The next method we'll talk about is the familiar Page Load event. It is in this event that most of our code that we want to run when the page loads will be placed. At this point ViewState is available and all controls that have been declared on the page have been handed the postback data. Note that if you have controls or user controls on the page, their individual Page_Load events will fire after the page's Page_Load event, in the order they were added to the control tree. The same is true for other controls events.

The PreRender event fires after the Page_Load events and after any controls events, such as a Button Click event. This is useful for manipulating anything you want, just before the page is rendered. One use is to store member variables in ViewState here to create a "Stateful" web page. To read the ViewState, we would re-hydrate the member variables in the Page Load event. Handling ViewState in this way, keeps the code in one place and creates a consistent state handling mechanism.

Finally, the page is rendered. We can override the Render event in controls to change the behavior of the control (useful for example when creating derived controls that extend the functionality of existing ASP Web Controls).

To give you an example of the execution sequence, here is the sequence from a page with one button and one user control that contains one button. The example shows the execution list after the user has clicked the button on the user control:

WebUserControl1_Init
WebForm1_Init
Page_Load
Page Button1_Load
WebUserControl1_Page_Load
UC1 Button1_Load
UC1 Button1_Click
WebForm1_PreRender
Page Button1_PreRender
WebUserControl1_PreRender
UC1 Button1_PreRender

Hope this is helpful. I'll address this in ASP.Net 2.0 in the near future.