On The Rocks

1. Maintain the position of the scrollbar on postbacks:  In ASP.NET 1.1 it was a pain to maintain the position of the scrollbar when doing a postback operation.  This was especially true when you had a grid on the page and went to edit a specific row.  Instead of staying on the desired row, the page would reload and you’d be placed back at the top and have to scroll down.  In ASP.NET 2.0 you can simply add the MaintainScrollPostionOnPostBack attribute to the Page directive:

   1:  

   2: <%@ Page Language=“C#” MaintainScrollPositionOnPostback=“true” 

   3:   AutoEventWireup=“true” CodeFile=“…” Inherits=“…” %> 

   4:  

2.  Set the default focus to a control when the page loads:  This is another extremely simple thing that can be done without resorting to writing JavaScript.  If you only have a single textbox (or two) on a page why should the user have to click in the textbox to start typing?  Shouldn’t the cursor already be blinking in the textbox so they can type away?  Using the DefaultFocus property of the HtmlForm control you can easily do this.

   1: <form id=”frm” DefaultFocus=”txtUserName” runat=”server”>

   2:   …

   3: </form> 

3. Set the default button that is triggered when the user hits the enter key:  This was a major pain point in ASP.NET 1.1 and required some JavaScript to be written to ensure that when the user hit the enter key that the appropriate button on the form triggered a “click” event on the server-side.  Fortunately, you can now use the HtmlForm control’s DefaultButton property to set which button should be clicked when the user hits enter.  This property is also available on the Panel control in cases where different buttons should be triggered as a user moves into different Panels on a page.

   1: <form id=”frm” DefaultButton=”btnSubmit” runat=”server”>

   2:   …

   3: </form> 

4. Locate nested controls easily: Finding controls within a Page’s control hierarchy can be painful but if you know how the controls are nested you can use the lesser known “$” shortcut to find controls without having to write recursive code.  If you’re looking for a great way to recursively find a control (in cases where you don’t know the exact control nesting) check out my good buddy Michael Palermo’s blog entry. The following example shows how to use the DefaultFocus property to set the focus on a textbox that is nested inside of a FormView control.  Notice that the “$” is used to delimit the nesting:

   1: <form id=”form1″ runat=”server” DefaultFocus=”formVw$txtName”>

   2: <div>

   3: <asp:FormView ID=”formVw” runat=”server”>

   4: <ItemTemplate>

   5: Name: 

   6: <asp:TextBox ID=”txtName” runat=”server” 

   7: Text=’<%# Eval(”FirstName”) + ” ” + Eval(”LastName”) %>’ />

   8: </ItemTemplate>

   9: </asp:FormView>

  10: </div>

  11: </form> 

This little trick can also be used on the server-side when calling FindControl().  I blogged about this awhile back if you’d like more details.  Here’s an example:

   1: TextBox tb = this.FindControl(“form1$formVw$txtName”) as TextBox;

   2: if (tb != null)

   3: {

   4: //Access TextBox control

   5: } 

5. Strongly-typed access to cross-page postback controls:  This one is a little more involved than the others, but quite useful.  ASP.NET 2.0 introduced the concept of cross-page postbacks where one page could postback information to a page other than itself.  This is done by setting the PostBackUrl property of a button to the name of the page that the button should postback data to.  Normally, the posted data can be accessed by doing something like PreviousPage.FindControl(”ControlID”).  However, this requires a cast if you need to access properties of the target control in the previous page (which you normally need to do).  If you add a public property into the code-behind page that initiates the postback operation, you can access the property in a strongly-typed manner by adding the PreviousPageType directive into the target page of the postback.  That may sound a little confusing if you haven’t done it so let me explain a little more.

If you have a page called Default.aspx that exposes a public property that returns a Textbox that is defined in the page, the page that data is posted to (lets call it SearchResults.aspx) can access that property in a strongly-typed manner (no FindControl() call is necessary) by adding the PreviousPageType directive into the top of the page:

   1: <%@ PreviousPageType VirtualPath=”Default.aspx” %> 

By adding this directive, the code in SearchResults.aspx can access the TextBox defined in Default.aspx in a strongly-typed manner.  The following example assumes the property defined in Default.aspx is named SearchTextBox.

   1: TextBox tb = PreviousPage.SearchTextBox; 

This code obviously only works if the previous page is Default.aspx.  PreviousPageType also has a TypeName property as well where you could define a base type that one or more pages derive from to make this technique work with multiple pages.  You can learn more about PreviousPageType here.

6. Strongly-typed access to Master Pages controls: The PreviousPageType directive isn’t the only one that provides strongly-typed access to controls.  If you have public properties defined in a Master Page that you’d like to access in a strongly-typed manner you can add the MasterType directive into a page as shown next (note that the MasterType directive also allows a TypeName to be defined as with the PreviousPageType directive):

   1: <%@ MasterType VirtualPath=”MasterPage.master” %> 

You can then access properties in the target master page from a content page by writing code like the following:

   1:  

   2: this.Master.HeaderText = “Label updated using MasterType directive with VirtualPath attribute.”; 

   3:  

   4:  

You can find several other tips and tricks related to working with master pages including sharing master pages across IIS virtual directories at a previous blog post I wrote. 

7. Validation groups: You may have a page that has multiple controls and multiple buttons.  When one of the buttons is clicked you want specific validator controls to be evaluated rather than all of the validators defined on the page.  With ASP.NET 1.1 there wasn’t a great way to handle this without resorting to some hack code.  ASP.NET 2.0 adds a ValidationGroup property to all validator controls and buttons (Button, LinkButton, etc.) that easily solves the problem.  If you have a TextBox at the top of a page that has a RequiredFieldValidator next to it and a Button control, you can fire that one validator when the button is clicked by setting the ValidationGroup property on the button and on the RequiredFieldValidator to the same value.  Any other validators not in the defined ValidationGroup will be ignored when the button is clicked. Here’s an example:

   1: <form id=”form1″ runat=”server”>

   2:     Search Text: <asp:TextBox ID=”txtSearch” runat=”server” /> 

   3:     <asp:RequiredFieldValidator ID=”valSearch” runat=”Server”

   4:       ControlToValidate=”txtSearch” ValidationGroup=”SearchGroup” /> 

   5:     <asp:Button ID=”btnSearch” runat=”server” Text=”Search”

   6: ValidationGroup=”SearchGroup” />

   7:     ….

   8:     Other controls with validators and buttons defined here

   9: </form>