<< ASP.NET 2.0 MultiView Control - No more TabStrip / Panel Show-Hide | Home | ASP.NET DataGrid - Custom Paging using the Cache Object - Part I >>

A better way of working with IE Webcontrols - Part II

I have written an article on the same lines some time back and thought of updating the same with a newer approach which came to my mind while implementing Tabstrip control in ASP.NET 1.1.

Fortunately, this has been very well replaced in ASP.NET 2.0 by using the MultiView - View Controls which provide an excellent mechanism for Tabbed Viewing or Partial Viewing of pages. Check my Recent Article on the same.

Well, now lets get back to ASP.NET 1.1, because I feel its still time for people to move to ASP.NET 2.0 and I am very much aware and used to the Clients who dont really want to jump for new technologies immediately, unless considerable number of implementations are made in the new technologies worldwide.

In ASP.NET 1.1, we dont have built in Tab strip control and we need to rely on the IE Webcontrols or other third party controls. The idea of third party controls is out of focus for this article and hence we would limit it to IE Tabstrip control.

An important point worth mentioning here is, IE Webcontrols are not supported by Microsoft and there is no reliability or scalability guarantee provided by Microsoft about these controls.

Ok, definitely now, I would get into business.

When implementing Tabs and Multipages in IE Tabstrip, we resort to showing different sections upon switching between different tabs.

However, there are certain limitations.

1. The Tab Index Change should happen at the client side and not at the server side. The server side is the default since AutoPostback is set to "true" by default. This causes a fractional ugly UI until the other tab loads.

2. For a single changed event, the whole page is reloading and thereby increasing the load.

3. You cannot have Validator controls across the tabs and happily submit one tab's data.

This happens because though the Tab shows different sections of the page, the validation is done at a Page Level as a whole where it checks the document.all (javascript function currently supported only by IE) or does a Page.IsValid in the case of server side.

So, in case we have a required field validator and a textbox and button in one tab, and a similar set of controls in another tab, no matter where you are, it wont allow you to submit the form unless all the validators, across the tabs are satisfied. This can partially be painful because sometimes you will keep clicking and wondering why the h*ll it is not submitting, when, actually if you switch to the other tab, it would be prettily showing the dreaded Red error messsage.

4. The controls you declare within the Tabstrip will not be automatically delcared in the codebehind and you have to manually declare them or do a FindControl everytime you want to access the properties.

5. In case you resort to Autopostback="false" scenario you have to explicitly load all the contents of the tabs and fetch any look up data being populated for all the tabs at one shot in the page_load, which may be a little slow in the beginning.

Well, though I keep complaining of the above points often, Tabstrip is still the only, trusted way of implementing Tab feature that I have seen across many projects.

Solution (not the best but definitely solves the purpose)

We can have the contents of each of the Tab in separate pages and provide an iframe link to those pages from the MultiPage defined for the Tabstrip.

Syntax

<IEWC:TABSTRIP id="Tabstrip1" runat="server" Visible="true" SelectedIndex="0" AutoPostBack="false" TargetID="MultiPage1">

<IEWC:TAB Text="Cricket"></IEWC:TAB>
<IEWC:TAB Text="Business"></IEWC:TAB>
<IEWC:TAB Text="Weather"></IEWC:TAB>
<IEWC:TAB Text="Stock"></IEWC:TAB>
<IEWC:TAB Text="Entertainment"></IEWC:TAB>
<IEWC:TAB Text="Health"></IEWC:TAB>

</IEWC:TABSTRIP>


<IEWC:MULTIPAGE id="MultiPage1" runat="server" Visible="true" BorderWidth="0px" Width="100%">

<IEWC:PAGEVIEW id="Cricket"> <iframe id="Iframe1" runat="server" src="Cricket.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe></IEWC:PAGEVIEW>

<IEWC:PAGEVIEW id="Business"> <iframe id="Iframe2" runat="server" src="Business.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe></IEWC:PAGEVIEW>

<IEWC:PAGEVIEW id="Weather"> <iframe id="Iframe3" runat="server" src="Weather.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe></IEWC:PAGEVIEW>

<IEWC:PAGEVIEW id="Stock"> <iframe id="Iframe4" runat="server" src="Stock.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe>
</IEWC:PAGEVIEW>

<IEWC:PAGEVIEW id="Entertainment"> <iframe id="Iframe4" runat="server" src="Entertainment.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe></IEWC:PAGEVIEW>

<IEWC:PAGEVIEW id="Health"> <iframe id="Iframe5" runat="server" src="Health.aspx" frameborder="0" width="100%" height="700px" scrolling="no"></iframe></IEWC:PAGEVIEW>

</IEWC:MULTIPAGE>

Thats it all about. If you see the above code, you can make out that I have mentioned different pages like Cricket.aspx, Weather.aspx etc., in the src attribute of the Iframes.

All of these pages are individual pages which can be developed independently and then linked to the tabstrip through the iframes.

The advantages of this approach

Pages can be developed independently, so debugging, control declaration, etc., will be simple.

Tomorrow, if we would like to remove one of the Tabs, its as simple as removing the <IEWC:Tab> and the respective MultiPage without worrying about the code corresponding to that Tab.

The Main page where we have our Tabstrip and Multipage becomes simple in terms of control tree, methods, debugging, maintenance etc.,

ASP.NET Validator Controls can exist happily across the tabs as each page can have its own Validator control and it doesnt stop the page corresponding to another tab's submission. This is because, the validators check at Page level and since all of them are individual pages, they dont stop the other page.

For every postback event raised within the Pages, only the corresponding page is loaded and not the entire main page with the Tab controls and they remain stable.

In case of Team Development, people can work independently on different pages and not worry about integration.

The true potential of this approach can only be recognized where you have a lot of Tabs and Multipages required in a single page.

Constraints
The pages may take a little time to load initially since the main page has to load different pages.

Communicating between the Tabbed pages become tricky.

Iframe is not the best recommended though it doesnt have any significant defect (Support for down level browsers might just be the only concern).

So, that concludes this article. Having said that, as already discussed, most of these issues have been take care in ASP.NET 2.0 and its just for the sake of ASP.NET 1.X Version where you need to rely on the IE Webcontrols.

Read Part I.

Cheers and Happy Programming !!!

Print | posted on Monday, December 19, 2005 3:54 AM

Comments on this post

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
Can u explain what u mean by the following:-)

In case you resort to Autopostback="false" scenario you have to explicitly load all the contents of the tabs and fetch any look up data being populated for all the tabs at one shot in the page_load, which may be a little slow in the beginning.
Left by Ahtims on Jan 17, 2006 4:02 PM

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
Thaks to u
Left by Anthony Kiran Kumar. Pagadala on Jan 30, 2006 9:41 AM

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
Your approach certainly serves very well & i`ve implemented it. But now just when am feelin good about it..i`ve come across the following issue:-
I have a tabstrip web control on my Main page(Main.aspx) which has 4 tabs say Add / Search / Admin Functions / Details.
Then i have a multipage with 4 iframes inside it to point src to the respective aspx pages.

Now lets say am in Search.aspx page, and from here i Redirect to some other Results.aspx page(not present in tabs)...
Note tht in this case...my tab selection shows Search when am on Results.aspx.

My question is: Is there a way to keep tht Search tab link active(i.e able to hit on it again) to go back to the Search.aspx page??

Ofcourse i can go to Search.aspx page from Results.aspx with the help of some button; but can we show up this Results page on some other tab which wud be dynamically created from Search page? I just want that Search tab link to be always active.

Plz help!
anagha
Left by Anagha on Oct 11, 2006 3:16 AM

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
Now lets say am in Search.aspx page, and from here i Redirect to some other Results.aspx page(not present in tabs)...
Note tht in this case...my tab selection shows Search when am on Results.aspx.
Left by mario oyunları on Sep 21, 2009 10:39 AM

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
Great follow up to your webcontrols guide. Thanks.
Left by Hack Habbo on May 11, 2010 10:47 PM

# re: A better way of working with IE Webcontrols - Part II

Requesting Gravatar...
I'm sure this is still pertinent even though it's an older post. Really taught me a lot.
Left by food trailer on May 17, 2010 4:40 AM

Your comment:

 (will show your gravatar)