When trying to open the Sitecore client (ie. by putting /sitecore in the URL), I got the following exception:
Exception: System.ArgumentNullException
Message: Value cannot be null.
Parameter name: item
Source: Sitecore.Kernel
at Sitecore.Diagnostics.Assert.ArgumentNotNull(Object argument, String argumentName)
at Sitecore.Web.UI.HtmlControls.Menu.AddFromDataSource(Item item, String target)
at Sitecore.Web.UI.HtmlControls.DataContextMenu.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
I noticed that the URL had changed to /sitecore/shell
With so few clues as to the cause, I simply entered the full path to the log-in screen (/sitecore/login). The log-in screen loaded and I was able to log in successfully.
Out of curiosity, I logged out again and then re-tried /sitecore on its own. The log-in screen opened OK that time. I've no idea as to the cause and I don't fancy investigating. If you're having the same problem, why not try what I did? Good luck.
Thursday, 9 July 2009
Wednesday, 8 July 2009
Save Settings to Web.Config file
Here's a quick snippet showing how to save a setting back to the web.config file. You are best wrapping this block in a try/catch in case the ASPNET user (or equivalent) does not have write access permissions to the file.
Configuration config = WebConfigurationManager.OpenWebConfiguration( "~/" );
AppSettingsSection appSettings = config.GetSection( "appSettings" ) as AppSettingsSection;
if ( appSettings != null )
{
if ( appSettings.Settings ["mySetting"] != null )
{
appSettings.Settings.Remove( "mySetting" );
}
appSettings.Settings.Add( "mySetting", text );
}
config.Save( ConfigurationSaveMode.Modified );
Configuration config = WebConfigurationManager.OpenWebConfiguration( "~/" );
AppSettingsSection appSettings = config.GetSection( "appSettings" ) as AppSettingsSection;
if ( appSettings != null )
{
if ( appSettings.Settings ["mySetting"] != null )
{
appSettings.Settings.Remove( "mySetting" );
}
appSettings.Settings.Add( "mySetting", text );
}
config.Save( ConfigurationSaveMode.Modified );
Labels:
ASP.NET,
C#,
Web.config
Wednesday, 15 April 2009
SqlParameter is Already Contained in Another SqlParameterCollection
This exception occurred between calls to a method I used to populate a SqlCommand object.
The solution was to clear the parameter collection at the end of the method (in a finally block, actually):
SqlCommand cmd = conn.CreateCommand();
...
foreach (SqlParameter sqlParameter in sqlParameters)
{
cmd.Parameters.Add(sqlParameter );
}
The solution was to clear the parameter collection at the end of the method (in a finally block, actually):
cmd.Parameters.Clear();
Labels:
C#,
SQL,
Troubleshooting
Thursday, 9 April 2009
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.

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.
Labels:
ASP.NET,
Troubleshooting
Friday, 16 January 2009
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:
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:
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>
Labels:
Accessibility,
JavaScript,
Tips
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:
To call the template, pass in the telephone number and prime the starting position using a value of 1:
If you’re using this within Sitecore, you can simply pass in a field value in the usual way:
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 <
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>
Labels:
Accessibility,
Screen readers,
Sitecore,
Tips,
Xslt
Friday, 19 December 2008
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.
Labels:
ASP.NET,
Troubleshooting
Subscribe to:
Posts (Atom)