If you have been doing SharePoint development for some time it is more than likely that you have developed your fair share of custom pages and custom controls/webparts for MOSS 2007. Where possible I try and leverage the existing SharePoint controls (such as the People Picker) to use on my pages as Microsoft has already done all the work developing these controls. One aspect I had never been able to get going until recently though was adding a spell checker control to my pages. I have just discovered that this is alot easier than I thought.

To add the out of the box spell checker all you need to do is:
1. Make sure you have the right page directive on the page you are adding the control to

<%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

2. To the head of your page, add the following controls, which will give you the javascript required for the spell checker to run:

<SharePoint:ScriptLink ID="ScriptLink1" Language="javascript" Name="core.js" runat="server" />
<SharePoint:ScriptLink ID="ScriptLink2" Language="javascript" Name="bform.js" runat="server" />
<SharePoint:ScriptLink ID="ScriptLink3" Language="javascript" Name="SpellCheckEntirePage.js" runat="server" />

3. Add the following block of javascript code to your page:

<script language="javascript" type="text/javascript">
function doSpellCheck() {
SpellCheckEntirePage('/_vti_bin/SpellCheck.asmx', '/_layouts/SpellChecker.aspx');
}</script>

4. Now all you need to do is create a link or a button which starts the spell checker. to this you just need to add the onclick javascript method 'doSpellCheck()' 

<a class="ms-toolbar" href="javascript:doSpellCheck()">Spelling...</a>

As a result of using this on click event, SharePoint will invoke a popup control which will enable your users to run a spell check against any input control that is on your page. Of course there might be certain controls on your page that you do not want to spell check against (such as People Pickers!) so all you need to do is add the attribute excludeFromSpellCheck="true" to any control that should not be spell checked:

<asp:TextBox ID="txtDontSpellCheck" runat="server" CssClass="ms-long" excludeFromSpellCheck="true"></asp:TextBox>

All in all, for a few lines of code, this really adds a heck of a lot of power and useability to your custom SharePoint pages!

Been doing heaps of stuff with jQuery lately, so thought I should start jotting down some of the more useable code that I have done.

A really useful bit of code was adding validation to check if at least one checkbox is checked. The following bit of code does that really easily.

First you will need to create a simple custom validator for your page:

<asp:CustomValidator ID="valCheckBoxes" runat="server"

                        ErrorMessage="You must select at least one checkbox"

                        ClientValidationFunction="CheckAnyCheckBoxChecked" Display="Dynamic"></asp:CustomValidator>

Once you have the validator, make sure that it has a ClientValidationFunction. You will then need to create this method. Using jQuery you can easily search for any checkbox that is checked. If none are checked, then throw the validation exception. Easy!!

<script type="text/javascript">

  function CheckAnyCheckBoxChecked(sender, args)

  {

    var isChecked = false;

    $("input[type=checkbox][checked]").each(

      function() {

         //Check if checkbox is checked

         if($(this).is(':checked'))

         {

            isChecked = true;

         }

      }

    );

    args.IsValid = isChecked;

    return;

  }

</script>

If you have specific checkboxes that you don't want to validate, then you can add a bit more jQuery to the script to check for specific items. Below I am doing a check on any checkbox that does not have the class 'NonMandatory' assigned to it (note:// I am using the parent check for the class as with ASP.NET the CSSClass of a checkbox is assigned to the span class that surrounds the checkbox control). 

<script type="text/javascript">

  function CheckAnyCheckBoxChecked(sender, args)

  {

    var isChecked = false;

    $("input[type=checkbox][checked]").each(

      function() {

        //Don't check for non mandatory check boxes

        if($(this).parent().hasClass('NonMandatory') == false)

        {

            //Check if checkbox is checked

            if($(this).is(':checked'))

            {

                isChecked = true;

            }

        }

      }

    );

    args.IsValid = isChecked;

    return;

  }

</script>

Twice in the past week I have had the issue in my MOSS code where it is throwing an exception:

"The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again"

As it turns out the problem isn't so had to fix. Basically you need to set FormDigestSettings to disabled. This can be done in your code as follows:

SPWebApplication webApp = site.WebApplication;
bool formDigestSettingsEnabled = webApp.FormDigestSettings.Enabled;
webApp.FormDigestSettings.Enabled = false;
//Do all your code in here where it is throwing the error..
webApp.FormDigestSettings.Enabled = formDigestSettingsEnabled;

This can also be fixed by turning off the security validation for an application in Central Admin (however I probably wouldn't recommend this):

Central Admin -> Application Management -> General Settings -> Turn security validation off

http://wiki.threewill.com/display/is/2007/10/.

Basically you need to call a javascript method called dispex() which will open the application for you (instead of opening the document as read only).

So within my code I already had my Hyperlink control (lnkDocumentDownload) which was populated by an SPListItem. This also has the URL of the document set in lnkDocumentDownload.NavigateUrl. This needs to be set for this to work, and of course for applications that don't have integration with SharePoint, they will just use this link to go to the document.

What I needed to additionally add to enable the launching of the application was:

lnkDocumentDownload.Attributes.Add(

Once I added this in, whenever I clicked the link in my control, it would behave in the same way as clicking on 'Edit in Microsoft Word'.

I also found some 'kind of' (not really) helpful documentation on the javascript methods on the Microsoft website here: http://msdn.microsoft.com/en-us/library/cc264013.aspx

'Longitude' is a third party product by BA Insight which extends SharePoint's search capabilities to deliver document page previews, relevance optimization, parametric navigation, enhanced sorting and a number of other additional features. In this presentation Clinton will cover MOSS Search and how businesses are using it, then will give a demo of Longitude highlighting how this can be used to extend SharePoint Search to deliver a more efficient and relevant search experience for end users.

A query that came through to me this week was could we display the content type for an item in the search results? …and the answer of course was yes. I wrote a little function to drop into the XSL to do this, which isn’t that pretty, but does work. Basically this query works by referencing each of the known SharePoint Content Types and giving them a friendly name.

This can easily be implemented into the search results web part in MOSS.

As such my (not so short) template is:

<xsl:template name="GetContentType">
    <xsl:param name="SharePointContentType"></xsl:param>
    <xsl:choose>
        <xsl:when test="contains($SharePointContentType,'STS_Web')">Site</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_850')">Page Library</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_850')">Page</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_DocumentLibrary')">Document Library</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_DocumentLibrary')">Document Library Items</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Links')">Links List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Links')">Links List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Tasks')">Tasks List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Tasks')">Tasks List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Events')">Events List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Events')">Events List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Announcements')">Announcements List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Announcements')">Announcements List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Contacts')">Contacts List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Contacts')">Contacts List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_DiscussionBoard')">Discussion List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_DiscussionBoard')">Discussion List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_IssueTracking')">Issue Tracking List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_IssueTracking')">Issue Tracking List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_GanttTasks')">Project Tasks List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_GanttTasks')">Project Tasks List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_Survey')">Survey List</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_Survey')">Survey List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_PictureLibrary')">Picture Library</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_PictureLibrary')">Picture Library Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_WebPageLibrary')">Web Page Library</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_WebPageLibrary')">Web Page Library Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List_XMLForm')">Form Library</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem_XMLForm')">Form Library Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_ListItem')">Custom List Item</xsl:when>
        <xsl:when test="contains($SharePointContentType,'STS_List')">Custom List</xsl:when>            
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSSearchQuery')">Search Query</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSListing:News')">News Listing</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSPeople')">People</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSCategory')">Category</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSListing')">Listing</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSPersonListing')">Person Listing</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSTextListing')">Text Listing</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSSiteListing')">Site Listing</xsl:when>
        <xsl:when test="contains($SharePointContentType,'urn:content-class:SPSSiteRegistry')">Site Registry Listing</xsl:when>
        <xsl:otherwise>
            Webpage (<xsl:value-of select="$SharePointContentType"/>)
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

Then to reference this in your search results simply call this template and pass in the variable ‘contentclass’ which appears on all search result pages:

<xsl:call-template name="GetContentType">
     <xsl:with-param name="SharePointContentType" select="contentclass"/>
</xsl:call-template>

I am (still) do heaps of work in SharePoint (MOSS) 2007 search which means I am (still) do heaps of work in XSL. An interesting task I had this week was to show and hide a body of text - however a brief summary of the text needed to be shown first, with the capability to expand the text to see more information. As there was no summary text per se, this meant the actual text needed to be shown partially, and when a link to show more is clicked, show it in it's entirety. Also, as part of keeping this all looking professional, the summary should not have any words chopped off.

Basically for the javascript show/hide we already had an existing bit of script I used, however if you need to try this out I thought I'd share this anyway:

<script type="text/javascript">
    function toggleLayer( whichLayer )
    {  
        var elem, vis;  
        if (document.getElementById) // this is the way the standards work
            elem = document.getElementById( whichLayer );  
        else if( document.all ) // this is the way old msie versions work
            elem = document.all[whichLayer];  
        else if( document.layers ) // this is the way nn4 works 
            elem = document.layers[whichLayer]; 
        vis = elem.style;          
        // if the style.display value is blank we try to figure it out here
        if(vis.display==''&&elem.offsetWidth!=undefined&&elem.offsetHeight!=undefined) 
            vis.display = (elem.offsetWidth!=0&&elem.offsetHeight!=0)?'block':'none';             
        vis.display = (vis.display==''||vis.display=='block')?'none':'block';
    }
</script> 

In order to specify the number of characters I was trimming initially, I added this as a simple XSL parameter to my XSL page ie:

<xsl:param name="AbstractSummaryLength">400</xsl:param> 

Next I created an XSL method called 'trim' which basically works by recursively calling itself to continue to trim until it reaches a space, and hence the end of a word.

 <xsl:template name="trim">
    <xsl:param name="in"/>
    <xsl:choose>
      <xsl:when test="substring($in, string-length($in), 1)=' '">
        <xsl:value-of select="$in"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:call-template name="trim">
          <xsl:with-param name="in"
              select="substring($in, 1, string-length($in)-1)"/>
        </xsl:call-template>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template> 

In order to get the summary of text (for a specified length) the substring method in XSL is great (assuming the field with our data is called 'abstract').

<xsl:variable name="summaryabstract" select="substring($abstract, 1, $AbstractSummaryLength)"/> 

We can then pass this value to the trim method to ensure we get an entire word at the end of the summary:

<xsl:variable name="summaryabstracttrimmed">
  <xsl:call-template name="trim">
    <xsl:with-param name="in" select="$summaryabstract"/>
  </xsl:call-template>                
</xsl:variable>
<xsl:variable name="abstractstartposition" select="string-length($summaryabstracttrimmed)"/> 

Finally, we just put together our variables and HTML, and we have a nice little piece of code to show and hide our full summary:

<!--Start of abstract-->
<div>
  <xsl:attribute name="id">AbstractSummary<xsl:value-of select="id"/></xsl:attribute>

  <xsl:value-of disable-output-escaping="yes" select="$summaryabstracttrimmed"/>

  [<a title="Show Abstract">
    <xsl:attribute name="href">
      javascript:toggleLayer('Abstract<xsl:value-of select="id"/>');
      javascript:toggleLayer('AbstractSummary<xsl:value-of select="id"/>');
    </xsl:attribute>more...</a>]  
 </div>             
<div style="display:none">
  <xsl:attribute name="id">Abstract<xsl:value-of select="id"/></xsl:attribute>
  
  <!-- Remainder of abstract-->
  <!--<xsl:value-of disable-output-escaping="yes" select="substring($abstract, $abstractstartposition)"/>-->
  
  <!-- Full abstract-->
  <xsl:value-of disable-output-escaping="yes" select="$abstract"/>

   [<a title="Hide Abstract">
     <xsl:attribute name="href">
      javascript:toggleLayer('Abstract<xsl:value-of select="id"/>');
       javascript:toggleLayer('AbstractSummary<xsl:value-of select="id"/>');
     </xsl:attribute>Hide</a>]
</div>
</xsl:if>

When using SharePoint 2007 you can often get troublesome web parts throwing errors which in turn causes the page not to load. This can often prove frustrating, especially if you need to close or delete a troublesome webpart, however can not get the page into edit mode in order to be able to do this. Luckily there is a way to easily view the ‘Manage Web Parts’ page which enables you to easily close or delete web parts from an easy to use interface.

In order to get this you simply need to use the path:

http://<SHAREPOINTSERVER>/_layouts/1033/spcontnt.aspx?&url=yourpage.aspx

This will give you a management screen for the web parts of the page entered in the query string (in the example above this would be ‘yourpage.aspx’.

The above example will work for pages located in the root site, however if you have sub sites, you will also need to add the sub site folder name to the URL string:

http://<SHAREPOINTSERVER>/SUBSITE/_layouts/1033/spcontnt.aspx?&url=/SUBSITE/yourpageaspx

I am sure that many of you use VPC images or similar for your development environments, and often the requirement will arise to create a new image based on an existing image - for a new developer or a new project or for a variety of other reasons. When developing with SharePoint 2007 (MOSS) and having this on your development environment, this can cause some serious headaches - mainly because you have to give the new image a new name (unless it is not on the same network) and as soon as you rename a SharePoint server it throws a hissy fit (as does SQL Server if this is also on  your development environment).

Anyway, I thought I'd share the steps that I go through when duplicated a SharePoint image (and these are pretty much the same steps as renaming an image should this be what you needed to do.

1. Go to the Sharepoint Central Administration > Operations > Services on Server  and stop "Windows SharePoint Services Search"
2. Rename your server, however wait until step 5 until you restart it
3. If you have MS SQL Server installed, you will also need to rename this. Go to "SQL Server Management Studio" and execute the following script
   
   EXEC sp_dropserver '<old_name>'
   GO
   EXEC sp_addserver '<new_name>', 'local'
   
4. Update SharePoint references of the new name by calling the script:
    stsadm -o renameserver -oldservername <old server name> -newservername <new server name>
5. Restart your PC
6. If you try to open Central Administration after restarting PC it will try to open the site with the old server name. To recreate your Central Administration site for the new server name, call the following command using a port number for the new location of central admin:
   psconfig -cmd adminvs -provision -port 12345 -windowsauthprovider onlyusentlm
7. Restart IIS and try to open your Central Admin site. It should successfully open your site with new server name
8. Go to the "Application Management" and remove websites that reference the old machine name
9. If you already have a search index drop this, and rebuild it

Now you should have a nicely renamed machine. You may find you need to create your site collections for SSP and My Sites, but this shouldn't be too hard.

UPDATE: Today I tried a different method of doing this which also works. I got the steps from a post on the SharePoint University site: http://www.sharepointblogs.com/mirjam/archive/2007/08/06/renaming-a-moss-server.aspx

Here are the steps:

Have you ever needed to update the web.config for your MOSS environment? This can be quite a difficult process as you need to modify it on every server in your farm, and of course monitor it. Today I stumbled over what seems like a pretty good way of doing this using some programming and a feature to deploy the changes. I haven't tried it yet, but probably will have to in the near future so will let you know how it goes.

In the meantime you can enlighten yourself by reading how to do it here.

Some time ago I wrote an article on styling the 'Best Bets' results in SharePoint. Recently I was looking at this XSL, and realised there is a much cleaner way of executing the same solution.

Instead of running a test within each match as per my first example, I think it is actually easier (and cleaner) to create a seperate xsl:template for all best bet results, which calls the individual xsl:template for each result.

So, for example, you would add a new template such as this:

<xsl:template match="Root/BestBetResults">    
  <xsl:if test="count(Result) > 0">
    <p>Recommended Results</p>    
    <xsl:apply-templates select="Result"/>
    <p>Search Results</p>
  </xsl:if>
</xsl:template>

Then you would need to adjust the result template as follows (and of course you can remove the checking to see if it is the first result etc.

<!--The Best Bets template-->
  <xsl:template match="Result">
    <xsl:if test="$DisplayBB = 'True'" >
      <xsl:if test="position() &lt;= $BBLimit" >
        ... <!-- Standard stuff in here -->
      </xsl:if>
    </xsl:if>
  </xsl:template>

I have previously written about one of the great under used features of MOSS 2007 which is email enabled lists, which enables users to be able to send content to an email address, and then have this content automatically appear in a SharePoint list. One of the unfortunate aspects of this is that it can be quite difficult and painful to setup, and there isn't always the most abundant amount of information floating around about it.

I recently setup email enabled lists for a client of mine's production environment but was having all kinds of difficulty. I installed the SMTP component of the setup on the application server, and email seemed to all send to Exchange fine and get into the SMTP queue on the SharePoint Application Server, however it never moved from this queue.

I realised after some playing around that the SMTP server should be on the web front end servers, however this wasn't of much use if I wanted to keep this separate in terms of the Farm setup for our environment. Fortunately I discovered a work around which seems to work fine, which is to create a share on the SMTP drop folder, give the SharePoint Timer Service account permissions to this file share, and then use this file share in the incoming mail settings.

So to configure this in central admin (after setting up the share on the incoming mail folder - by default c:\inetpub\mailroot\drop):

1. Go to 'Configure incoming e-mail settings'
2. Set 'Enable Incoming E-mail' 'Settings mode' to 'Advanced'
3. Set the e-mail drop folder to the shared folder
   eg \\<SMTPSERVER>\drop$

One of the features of SharePoint 2007 (MOSS) is that when you can easily make templates out of any custom list you are using. Once you create a template of this list, this template can be easily used by other users of SharePoint if they want to create a similiar list. These lists simply append themselves to the create page in SharePoint (http://<sharepoint>/_layouts/create.aspx). This is a great little add in to have, however sometimes you want to target these various custom lists at different groups of users, or hide them all together, however don't want to delete them from the List Template Gallery. Luckily there is an easy fix for this.

Simply go to the List Template Gallery (http://<sharepoint>/_catalogs/lt/Forms/AllItems.aspx) then

1. Either create a new view or edit the existing view.
2. In the columns list, make sure you check the column name 'Name (linked to document with edit menu)'
3. Save the view

Now when you go to the items in the list template gallery, you will now have a context menu to edit the permissions for each item in the gallery. To hide these items from different groups of viewers, simply change the permissions for who can access the various items in this gallery. If a user doesn't have any access to the item, then it will not appear on their create page in SharePoint, as this is automatically security trimmed!

I was having to do some work today in JavaScript where I was building URL's using variables passed to the script. One of the variables that I had to pass was the URL, and as part of this came across the issue that in appending the querystring value to the URL, that the URL may already have a value for the querystring.

However after a little scope around the web I found a nice little bit of javascript that checks the URL for the querystring value, and replaces it if required using a regular expression - so I thought I'd share it. Neat. Easy.

function replaceQueryString(url,param,value) {
    var re = new RegExp("([?|&])" + param + "=.*?(&|$)","i");
    if (url.match(re))
        return url.replace(re,'$1' + param + "=" + value + '$2');
    else
        return url + '&' + param + "=" + value;
}