Button click event handler fires twice

I had a simple button on a form together with its click event handler. On debugging, I noticed that the event handler was firing twice. After a long investigation, I decided to check the HTTP headers. These revealed that the "Display Page Validation" option I was using in the Tools menu of the Web Dev toolbar in Firefox was the culprit.



When switched on, this runs the handler a second time, submitting the results to a validator at w3.org. This is something to bear in mind, particularly for code that must only run once, such as handling credit card payments.

Accessible print-friendly web pages

There are times when you might want to render a page specifically for printing (rather than using CSS). For example you might want to include or exclude specific information on the printed page. When users view the print-friendly page, you might want to include some instructions at the top of the page, but not have these themselves print out. You might want to let users know they are viewing a print-friendly version and provide them with a link back to the on-screen view.

You can do this by first defining a “noprint” class:

    <style type="text/css">
        @media print
        {
            .noprint
            {
                display: none;
            }
        }
    </style>

You can then include your instructions in a DIV having this class.

Typically, the next action a user will take on viewing the page is to open the print dialogue box. We could attach a “window.print()” JavaScript action to the body’s onload event, or within a <script> tag somewhere in the body. However, having a dialogue box appear automatically is not particularly accessible as it changes the focus. The alternative is to insert a “print this page” link if the browser supports JavaScript. For non-JavaScript browsers, simply inform the user to use his or her browser’s print menu. This is demonstrated by the following HTML:

    <div class="noprint" style="background-color: #eeeeee;
border: solid 1px black; padding: 10px 10px 10px 10px;">
        <p>
            You are viewing a print-friendly version
 of a page.</p>
        <p>

            <script type="text/javascript">
                var str = "Print this page";
                document.write(
str.link("javascript:window.print()"));
            </script>

        </p>
        <noscript>
            <p>
                Please select print from your browser’s
menu to print the page</p>
        </noscript>
        <p>
            or <a href="/path/file.htm">
return to the normal on-screen view of the page
            </a>
        </p>
    </div>

Screen reader friendly phone numbers

When you display a telephone number on screen, screen readers read it out as a single number. The Fangs screen reader emulator (see http://sourceforge.net/projects/fangs) reads the number (01234) 567890 as “left paren six hundred sixty-eight right paren five hundred sixty-seven thousand eight hundred ninety”. The “six hundred sixty-eight” bit is particularly curious: the 01234 is being interpreted as an octal number.

By encasing each digit within a <span /> tag, the digits are read out individually. So, (01234) 567890 becomes “left paren zero one two three four right paren five six seven eight nine zero”.

I have written an XSLT template that takes a phone number and applies a <span /> to each digit:

  <xsl:template name="DisplayPhoneNumber">
    <xsl:param name="position" />
    <xsl:param name="phonenumber" />
    <xsl:variable name="digit"
select="substring($phonenumber, $position, 1)" />

    <xsl:choose>
      <xsl:when test="contains('012345678', $digit)">
        <span>
          <xsl:value-of select="$digit" />
        </span>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$digit" />
      </xsl:otherwise>
    </xsl:choose>

    <xsl:if test="$position &lt;
string-length($phonenumber)">
      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position">
          <xsl:value-of select="$position+1" />
        </xsl:with-param>
        <xsl:with-param name="phonenumber"
select="$phonenumber" />
      </xsl:call-template>
    </xsl:if>
  </xsl:template>

To call the template, pass in the telephone number and prime the starting position using a value of 1:

      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position" select="'1'" />
        <xsl:with-param name="phonenumber"
select="'(01234) 567890'" />
      </xsl:call-template>

If you’re using this within Sitecore, you can simply pass in a field value in the usual way:

      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position" select="'1'" />
        <xsl:with-param name="phonenumber"
select="sc:fld('phone', .)" />
      </xsl:call-template>

Loading this assembly would produce a different grant set from other instances

If you get this exception message when trying to browse an ASP.NET site you are developing, first stop the site in IIS, then clear out the ASP.NET Temporary Files folder that relate to your site (default location is under C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files). Then start IIS and try browsing the site.

Localhost on IIS7

By default, browsing to localhost on IIS7 brings up a welcome screen. To associate localhost with a particular web site, right-click the web site in IIS7 and select "Edit Bindings" (or just "Bindings", depending on which pane you were in when you right-clicked; IIS is still as inconsistent as ever!). In the "Add Site Binding" dialogue box, add localhost as a host name. Apply the changes. You will now be able to browse to localhost.

Visual Studio External Tools Menu

Further to my post about setting up Windows Explorer as an external tool within Visual Studio (http://www.neilpullinger.co.uk/2008/03/open-visual-studio-project-folder-in.html), I have set up a number of other tools set up in the same way. Here's my list now:

Title	Command	Arguments	Notes
Run test	(full path to nunit.exe)	$(ItemPath)
Reflector	(full path to reflector.exe)	$(ItemPath)
FxCop	(full path to fxcop.exe)	$(TargetPath)
Explorer	(full path to explorer.exe)	/e, /select, $(ItemPath)
Open in Notepad	(full path to notepad.exe)	$(ItemPath)
Open	(full path to a batch file containing just "%1")	$(ItemPath)
Error Lookup	(errlook.exe, in VS\Common\Tools folder)	(none)	Not sure where this one came from; installed by default?
Spy++	(spyxx.exe, in VS\Common\Tools folder)	(none)	Installed by default

I've excluded a couple of the others that are there by default (eg. Create Guid and Dotfuscator).

(Edited 19/12/2008)

Always set AutoPage to true in LinqDataSource

If you are binding a control to a LinqDataSource, always set the AutoPage property on the LinqDataSource to true (AutoPage=“true”) if you have enabled paging on the data-bound control. Without the AutoPage option set, the LinqDataSource will pull back all records in the data source every time a page is browsed. Not only is this inefficient and not scalable, but it allows the client to determine the level of resources required, which is not good practice.

<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="MyDataContext" TableName="MyTable" AutoPage="true"></asp:LinqDataSource>

Sadly, the AutoPage option doesn’t seem to be available in other DataSource objects, so a manual implementation is necessary for these.