Friday, November 30, 2007

ASP.NET Page Life Cycle

1. Object Initialization

A page’s controls (and the page itself) are first initialized in their raw form. By declaring your objects within the constructor of your C# code-behind file (see Figure 1), the page knows what types of objects and how many to create. Once you have declared your objects within your constructor, you may then access them from any sub class, method, event, or property. However, if any of your objects are controls specified within your ASPX file, at this point the controls have no attributes or properties. It is dangerous to access them through code, as there is no guarantee of what order the control instances will be created (if they are created at all). The initialization event can be overridden using the OnInit method.


2. Load Viewstate Data

After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). At LoadViewState event, the initialized controls receive their first properties: viewstate information that was persisted back to the server on the last submission. The page viewstate is managed by ASP.NET and is used to persist information over a page roundtrip to the server. Viewstate information is saved as a string of name/value pairs and contains information such as control text or value. The viewstate is held in the value property of a hidden control that is passed from page request to page request. As you can see, this is a giant leap forward from the old ASP 3.0 techniques of maintaining state. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated. Figure 2 shows an example of overriding and setting viewstate at the LoadViewState event.


3. LoadPostData Processes Postback Data

During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) is processed against each control that requires it. When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data. The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data. ASP.NET updates the correct control by matching the control’s unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique IDs for each control on any given page. Extra steps are taken by the framework to ensure each ID is unique in situations, such as several custom user controls existing on a single page. After the LoadPostData event triggers, the RaisePostDataChanged event is free to execute.


4. Object Load

Objects take true form during the Load event. All object are first arranged in the page DOM (called the Control Tree in ASP.NET) and can be referenced easily through code or relative position (crawling the DOM). Objects are then free to retrieve the client-side properties set in the HTML, such as width, value, or visibility. During Load, coded logic, such as arithmetic, setting control properties programmatically, and using the StringBuilder to assemble a string for output, is also executed. This stage is where the majority of work happens.


5. Raise PostBack Change Events

As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. During this operation, each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. ASP.NET then sweeps through the page looking for flags indicating that any object’s data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data.


6. Process Client-Side PostBack Event

After the server-side events fire on data that was changed due to postback updates, the object which caused the postback is handled at the RaisePostBackEvent event. The offending object is usually a control that posted the page back to the server due to a state change (with autopostback enabled) or a form submit button that was clicked. There is often code that will execute in this event, as this is an ideal location to handle event-driven logic. The RaisePostBackEvent event fires last in the series of postback events due to the accuracy of the data that is rendered to the browser.
Controls that are changed during postback should not be updated after the executing function is called due to the consistency factor. That is, data that is changed by an anticipated event should always be reflected in the resulting page.


7. Prerender the Objects

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to viewstate. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or viewstate updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page viewstate. The PreRender step can be overridden using OnPreRender .


8. ViewState Saved

The viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not.


9. Render To HTML

The Render event commences the building of the page by assembling the HTML for output to the browser. During the Render event, the page calls on the objects to render themselves into HTML. The page then collects the HTML for delivery. When the Render event is overridden, the developer can write custom HTML to the browser that nullifies all the HTML the page has created thus far. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser. Changes can still be made at this point, but they are reflected to the client only.


10. Disposal

After the page’s HTML is rendered, the objects are disposed of. During the Dispose event, you should destroy any objects or references you have created in building the page. At this point, all processing has occurred and it is safe to dispose of any remaining objects, including the Page object. You can override Dispose.

Reference : -http://www.techinterviews.com/?p=176

Tuesday, November 27, 2007

Alternate text for images for different browsers


To show any picture or image on the webpage either img tag is used or <asp:Image> tag is used. We also put some alternate text for the image. Alternate text can be used to show some details on the screen related to the image. Alternate text is displayed when mouse is over the image. Internet explorer shows a cross sign which means that image is not available on the server where FireFox shows the alternate text on the screen instead of cross sign.

To show alternate text on the image we use
"alt" attribute for img tag .
"Alternatetext" attribute for asp:Image.

But the funny side of these attributes is they are not supported by Firefox. If you use any of these attribute to show alternate text then alternate text is not displayed in Firefox.

After some hard work I found a common solution which is supported by most browsers. Solution is to use " title" attribute instead of "alt" attribute. This attribute is supported by all the browsers.
<img src="sunset.jpg" title="Image1"> </img>

So if you are making an application for different browser stop using alt attribute and switch to title attribute.

Enjoy.

Wednesday, November 14, 2007

TOP WITH TIES clause in SELECT queries


The SELECT TOP N query always returns exactly N records, and randomly drops any record that have the same value as the last record in the group.

SELECT TOP 5 price, Booktitle FROM BookTitles ORDER BY price DESC

This query will give 5 records from table BookTitles in descending order by price. Problem over here is Suppose the last book title has a price tag of $19.99. The BookTitles table contains two more books with the same price, but they are ignored by the TOP clause.

To see those recrods add the WITH TIES clause...

SELECT TOP 5 WITH TIES price, Booktitle FROM BookTitles ORDER BY price DESC

**WITH TIES will only work with Order by Clause.

Tuesday, November 13, 2007

How to display your own logo in the address bar?


If you need to put your website logo in the top address bar instead of browser's logo then follow these steps.
1. Add a file called "favicon.ico" (an icon file of your website logo) to your website root directory.
2.Insert the following HTML tag inside the <head> ... </head> section of your web page.
<link rel="shortcut icon" href="favicon.ico" >

**If you are working with master pages then put this code in head section of master page otherwise you have to put this code in every page.

Enjoy...

Sunday, November 04, 2007

Asp.Net 2.0 File Upload Control


ASP.Net 2.0 comes up with a completely new File Upload Control. This is how you can declare the file upload control.
<asp:FileUpload id="FileUpload1" runat="server" />

Here are some useful properties:-
FileUpload1.FileName :- Will give File Name with the full Path. FileUpload1.PostedFile.FileName :- Will give only the file name. FileUpload1.PostedFile.ContentLength :- will give size of the file in Bytes. FileUpload1.PostedFile.ContentType :- will give MIME type of uploaded file, i.e. "image/gif".

**Don't use file upload control within Update Panel as it is not supported by update panel.

By Default, maximum allowed size for file is 4MB. To allow files larger than the default of 4MB, one need to change the web.config.There is a parameter called maxRequestLength which takes value in the KB.

<system.web>
<httpRuntime executionTimeout="1000" maxRequestLength="1048576"/>
</system.web>

The maxRequestLength property dictates the size of the request made to the Web server.When you upload files, the file is included in the request.

This example changes the maxRequestLength property's value to 1048576KB (around 1GB). With this setting in place, end users can upload 1Gb file to the server.

There is a one more property named "executionTimeout".This property sets the time (in seconds) for a request to attempt to execute to the server before ASP.NET shuts down the request (whether or not it is finished). The default setting is 90 seconds.
The end user receives a timeout error notification in the browser if the time limit is exceeded. If you are going to permit larger requests, remember that they take longer to execute than smaller ones. If you increase the size of the maxRequestLength property, you should examine whether to increase the executionTimeout property as well.

Uploading files in ASP.NET is very inefficient.When you pick a file and submit your form, IIS needs to suck it all in and only then you have access to the properties of uploaded file(s).You can not do about the fact that you have to sit through a long upload and wait. Neither can you display a meaningful progress bar because there’s no way to know how much is transmitted at any given time.Once IIS buffers your upload, ASP.NET takes it from there.

You might receive errors when your end users upload files to your Web server through the FileUpload control in your application. These might occur because the destination folder on the server is not writable for the account used by ASP.NET. If ASP.NET is not enabled to write to the folder you want, you can enable it using the folder's properties.
back to top