There are a few web parts out there that will automatically scroll through your lists. These are pretty and work well. They will slowly scroll through your lists like a news ticker. My issue with these is that my primary customers are police officers, and very rarely do they want to slowly read through a list. Most of my  police department customers' roll call lists have dozens of items, all active and all urgent (it being roll call and all). They didn't want to wait slowly during roll call at the beginning of their shift to read through the items. Also, they wanted all of the items to show on the home page, or at least easily accessible, and always the high priorities should be on top. As you can see, an automatic scrolling web part would've been useless.

My solution was to basically setup their roll call list to a set height and then allow them to scroll through it themselves. For whatever reason the web part properties Height doesn't work for me, does it for you? Using SharePoint Designer (SPD), we can achieve this setup in about 5 minutes. Using my development site, you'll see my announcement list is long and pushing the page down.

Open the site in SharePoint Designer. Copy the page before making any modifications. Right click the web part and select Convert to XSLT Data View. You will then notice your web part is broken into multiple elements.

Also, you may notice that the Body of the item has been removed. I'm not sure why that happens but that's okay, we add it later using a different method.

Next, switch SPD to Split view, to view the code above the design view page. (the option is in the lower left of the window.)

Click on an item in the design view, say the first announcement. Above the code view is a path of tags, similar to the following:

Looking at this line, starting on the right, read it from right to left and find the second <TABLE> tag, the first one might look like <TABLE#-.ms-summarycus..>. Click the <TABLE> tag and the code for the table will be selected in the code view. With any luck, you should see the following selected.

The key here is the <xsl:otherwise> tag right before your selected <TABLE> tag. Click there and insert the following:

<div style="height: 250px;overflow:auto">

When you do, the closing </div> tag will appear, delete that, we'll add it later. You should now have something like:

Next, we add the closing </div> tag. Scroll down in the code about 90-100 lines, depending on your list and fields selected. Look for this:

Right after the second </TABLE> you want to put in </div>. You should now having something like:

Click in the design view half and SPD will recompile the page and you should see the list in it's entirity. SPD doesn't recognize the height style. As long as you're not getting an XSLT error you should be all set to save and test in Internet Explorer.

My list now has a scroll bar allowing users to view it all on this same page.

Now lets add the body in there. The issue with the body is that we only want to show 250 characters, and when we clip it short we are also clipping off possible closing HTML tags in the body. For example, a rich text body might contain <div>This is a test body...</div>. Say we clip it off before the closing </div> tag we'll have an open <div> tag which that breaks the page, pretty good at that too. So in the XSL code for the web part we need to remove the HTML tags before showing the body. Thanks to Vincent for his post on how to strip out HTML tags http://blog.thekid.me.uk/archive/2007/05/17/stripping-html-tags-when-using-xslt.aspx.

Back in SPD, scroll up above where you added the <div style="height: 250px;overflow:auto"> and look for a <xsl:template name="dvt_1">. Above this tag should be a </xsl:template> tag. We are going to insert the following code right between these two:

<xsl:template name="removeHtmlTags">
    <xsl:param name="html"/>
    <xsl:choose>
        <xsl:when test="contains($html, '&lt;')">
            <xsl:value-of select="substring-before($html, '&lt;')"/>
            <!-- Recurse through HTML -->
            <xsl:call-template name="removeHtmlTags">
                <xsl:with-param name="html" select="substring-after($html, '&gt;')"/>
            </xsl:call-template>
        </xsl:when>
        <xsl:otherwise>
            <xsl:value-of select="$html"/>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

so now you should have something like:

Next, click in the design view on a user's name after the "by" in one of the announcements. Code view should highlight the associated <xsl:value-of> tag. This <xsl:value-of> tag is inside of an <xsl:choose> tag. Step outside of this tag, below the selected line. Add the following after the </xsl:choose> and before the </TD> tag.

<xsl:variable name="pureText">
    <xsl:call-template name="removeHtmlTags">
        <xsl:with-param name="html" select="@Body" />
    </xsl:call-template>
</xsl:variable>

<div class="blogText">
    <xsl:value-of select="substring($pureText, 0, 250)" />...<br/>
</div>

You should have something like this:

Click the design view and you'll see your comments. Save the file and you'll have the comments in SharePoint. Check it out!

That should do it! Let me know what you think or if you have questions!

I recently had to create some functionality for a customer to take a subsite, and duplicate it for backup purposes. I would normally walk them through the process using stsadm or use Save Site as Template but they wanted a simple method of doing it. I created them a on click solution.

My code is below. We were going to move forward with the SPWeb SaveAsTemplate option but the site was too large. Even after increasing the template size SharePoint still errored. See KB Article 960969 for more details. So instead we are using stsadm and exporting the site then importing it.

Exporting a Site

Process exportSite = new Process();

string commonFilesPath = System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonProgramFiles);
string commandLine = " -o export -url " + SPContext.Current.Web.Url + " -filename c:\\" + tempName + ".exp -overwrite -includeusersecurity";

exportSite.StartInfo.UseShellExecute = true;
exportSite.StartInfo.FileName = commonFilesPath + @"\Microsoft Shared\web server extensions\12\BIN\" + "stsadm.exe ";
exportSite.StartInfo.Arguments = commandLine;
exportSite.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
exportSite.Start();
exportSite.Close();

Importing a Site

Process importSite = new Process();
string commonFilesPath = System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonProgramFiles);
string commandLine = " -o import -url " + SPContext.Current.Web.Url + "/" + tempName + " -filename c:\\" + tempName + ".exp -includeusersecurity";

importSite.StartInfo.UseShellExecute = true;
importSite.StartInfo.FileName = commonFilesPath + @"\Microsoft Shared\web server extensions\12\BIN\" + "stsadm.exe ";
importSite.StartInfo.Arguments = commandLine;
importSite.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
importSite.Start();
importSite.Close();

Hope this helps! If you have a better method I would love to hear it, I'm always looking for ways to improve!!

Google recently published a new tool to help web designers and developers assess the real estate on their pages. It's a basic tool which overlays a standard graph over your pages showing you the percentage of visitors who have their browsers open to the specific size. Check it out at http://browsersize.googlelabs.com/.

I played around with it a bit and found it a little too elementary. Any good web designer knows that you have to stay above the fold and shouldn't exceed certain widths. If you web page is centered, the tool doesn't take that into account so it'll show that your page won't be seen by 20% of your visitors, for example, using our site on my screen at 1920x1080, their tools shows this:

Only 80% of my visitors will see half of the page. Apparantely that's not accurate. If I resize my browser to 1024x768, it's more accurate.

Now it shows that only 5% of the visitors may not see the full width. According to Google, "Browser Size works best on web pages with a fixed layout aligned to the left. If the content reflows as the width is adjusted or it is centered, then the results can be misleading. In this case, you can obtain more accurate results by reducing the browser width to a percentage column, e.g. 90% and seeing what content falls below the 90% horizontal line."

One more thing that is nice, you can specify an internal web address as well. For instance, if you are developing a site and want to check out the browser size, simply type in the internal URL and blamo you're comparing it to your internal address. It appears the window displaying the website is client based not server based.

I watch this tool with anticipation, it has potential of being a great tool. Integrating it with their Google Analytics would be REAL nice too.

As a SharePoint developer, you may be creating a web part and for the sake of testing you throw it up on your site. Then you decide to rename your class or get a new public key token for your class or something like that. After doing so, your page might stop loading with the following error.

You may not be a developer, you simply obtained a web part from another party and now it's not working and you get the following error.

An error occurred during the processing of . Could not load file or assembly 'Class.Class, Version=1.0.0.0, Culture=neutral, PublicKeyToken=20f2595270a5ec23' or one of its dependencies. The system cannot find the file specified

If you're lucky you are running into this on your default.aspx so clicking Go back to site doesn't work. If you want the fix, scroll down to The Fix. Or read on to understand what's going on.

In my own understanding, the issue is as follows:

When you add a web part to a page the web part's associated assembly is registered in the page, i.e.:

Screen shot from SharePoint Designer.

As you can see in lines 1 and 2, there are register tags for my two web parts I have on my page. The registers call on the entire assembly of the class the web part uses, which is what the page is erroring on. Normally, if you close a web part on a page through the web interface the web part doesn't get removed from the page, it's just invisible. In SharePoint Designer (SPD) the web part appears grayed out and the register tag remains on the page. Get SharePoint Designer for free!

To have the web part reappear, using SPD, change the __designer:IsClosed property of the web part from true to false. Save the page and your web part is back.

So how do we properly get rid of a web part? This is not the fix to the error, this is how to prevent receiving the error in the future. Instead of just closing the web part, you need to delete it.

To do so, go to Site Actions then Edit Page. Then click the Edit menu for the web part and you'll see Delete. Click to remove the web part, and it's registered tag from the page.

You won't need to do this for resident SharePoint web parts, like views of lists and libraries. This will be necessary for any third party custom web part.

The Fix

On to the fix. If it's too late for you, and the web part was already closed or removed or uninstalled and you're getting this error, try these steps:

1. Go to http://servername/_layouts/settings.aspx. This should bring you to the Site Settings page.
2. Click Reset to site definition in the Look and Feel column.
3. Enter the full URL to the page that is erroring.
4. Click Reset and confirm.

This functionality resets the page entirely so if you have any customizations on the page itself, it will remove them all. It does not appear however to remove other custom web parts that are installed.

I hope this helps!

A growing commonality we're seeing is allowing external visitor access to SharePoint, whether it's a police department rolling it out their community or an organization wanting to allow it's 80+ volunteers access. The most cost effective way to do this is to use forms authentication and SQL server to store the membership database. You can use the same Active Directory your site is running on now but then you need to license each user in your network. Using SQL server stores the user accounts in the SQL database and therefore doesn't require any CALs for authentication. If you are using Microsoft Office SharePoint Server (MOSS) you will still require purchasing MOSS CALs for each user.

These steps I walk through pertain to Windows SharePoint Services (WSS). I have not tried these on MOSS, but I'm guessing it'll work there as well.

Before you begin, note that when you're completed, SharePoint will be looking at SQL for user accounts but SharePoint does not include the necessary tools to add, edit or reset passwords for users. You will have to create your own or find a third party solution. We have a solution available, email sales for more information.

1) Create the SharePoint site collection.

This might be a given, but make sure your SharePoint site is up and running. You cannot configure forms authentication on a site that doens't exist.

2) Extend the site to a new zone.

Go to Central Administration, then Application Management. Click Create or extend Web Application. On the next page click Extend an existing Web application.

On the extend web application page:

• Web Application : Select the site you want to enable SQL authentication
• IIS Web Site : Type in the port (80 unless you want a non-standard port, use 443 for SSL) and host header (web address) you want your SQL users to access. It cannot be the same address as the existing AD site.
• Security Configuration : Keep the defaults unless you want to enable SSL.
• Load Balanced URL : Keep the URL the way it is, it should reflect the host header you entered above. Under Zone, select a zone name that correctly categorizes the site you're extending.

Click OK. Your site is now accessible from both web addresses; the original address that was setup and now the new one. If you were to look in IIS you will see the new site setup. Now that it is a unique instance, we can now configure it for Forms Authentication.

3) Install Membership Provider to SQL Server.

See http://msdn.microsoft.com/en-us/library/ms229862.aspx for more information on how to install the membership provider. During the installation process I install the membership provider to the Content database the site is using. This helps keep everything in one place in the event we need to move it.

4) Configure Zone for Forms Authentication.

Back in Central Administration, go to Authentication Providers in Application Management. Make sure you have your site selected in the Web Application selector. You should see two zones: Default and the other one you created. Click the second zone you created.

On the Edit authentication page:

• Authentication Type : Select Forms. The page will reload with new options.
• Membership Provider Name : Enter AspNetSqlMembershipProvider. We will be using this same name a little later.
• Role Manager Name : Enter AspNetSqlRoleProvier. Again, we will be using this later.
• Client Integration : I recommend keeping this set to No. Enabling Yes could cause some issues.

Click Save. Next we will configure the sites to use your SQL server for the membership provider

5) Configure Extended Web Site Membership Provider

Open Windows Explorer (My Computer) and browse to c:\inetpub\wwwroot\wss\virtualdirectories. Within this folder you will see a folder for each SharePoint site hosted on your server. Open the folder that contains the new address you extended the site to. Next, right click the file web.config and Open it with Notepad. If you're using Windows Server 2008, open Notepad as administrator first, then open the web.config file.

Within the web.config file:

Locate </configSections> and copy the following immediately after it.

<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Data Source=servername;Initial Catalog=databasename;Integrated Security=SSPI" />
</connectionStrings>

Enter the server name and database where you installed the membership provider in step 3. Note Integrated Security option in the connection string. You will require to setup the security account that SharePoint is running on to have access to the SQL server if it doesn't already.

Locate <system.web> and copy the following immediately after it.

<roleManager>
<providers>
<remove name="AspNetSqlRoleProvider" />
<add name="AspNetSqlRoleProvider" connectionStringName="LocalSqlServer" applicationName="/wss" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
<membership>
<providers>
<remove name="AspNetSqlMembershipProvider" />
<add connectionStringName="LocalSqlServer" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/wss" requiresUniqueEmail="false" passwordFormat="Clear" maxInvalidPasswordAttempts="15" minRequiredPasswordLength="5" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="1" passwordStrengthRegularExpression="" name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>

The applicationName (appears twice above) should mirror your site's name or something unique. If you extend another SharePoint site at a later point to use SQL, you'll want to use a different applicationName.

Save and close the web.config file.

6) Configure Central Admin Membership Provider

In order for Central Administration to know anything about your SQL users you need to replicate the same settings in the Central Admin web.config file. In Windows Explorer browse to C:\inetpub\wwwroot\wss\virtualdirectories and open the folder that matches the same port number that Central Admin uses. Open the web.config file in the same manner you did in step 5 and update in the same way.

You're all set!

You should be good to go! Browse to the new web address and you'll be prompted with a forms based sign in. As I said before these steps, you will need to setup a custom application to manage the user accounts in SQL. SharePoint does not include this functionality. We have a solution available, email sales for more information.

Unfortunately I know this first hand. We were working on a customer's SharePoint instance and had to uninstall a feature. So using stsadm we went to uninstall the feature and forgot to include the feature part of the command. So we ran stsadm -o uninstall........... and uninstall it did! It completely uninstalled SharePoint from the server with no prompt or warning! The only thing left was the configuration wizard and the IIS websites were stopped.

I reran the configuration wizard and received error after error. So I went to Add/Remove programs and completely uninstalled SharePoint and reinstalled it. When running the config wizard I tried connecting to the same farm and recieved the same errors. So instead I went ahead and created a new farm and the install ran fine.

Once in the new Central Admin, I reconfigured everything, added the features back in using stsadm and viola, we're back in business...

Microsoft, please remove this awesome feature, it's too cool for us little people!

In one of my customer's MOSS implementations we're using SharePoint's resident permission management to control who has access to what InfoPath forms. The issue we came across is that if a user has read-only access to a form and opens it, they can see the Update button. Clicking it does error and denies the change, and after the error the user gets the typical form closed message.

We wanted to hide the button from the view of a user who has read-only permissions to deny the error all together and minimize user complaints.

Using the code behind in the InfoPath form, we can check the current user against the current item then set a field in InfoPath to flag whether or not the user is read-only or not. From there, we can base the conditional formatting of buttons, text boxes, etc. on this value.

try
{
 if (e.InputParameters.ContainsKey("XmlLocation") && !SPContext.Current.Web.CurrentUser.IsSiteAdmin)  //Regardless of resident permissions, give SiteAdmins access
 {
  SPUser curUser = SPContext.Current.Web.CurrentUser;
  string path = e.InputParameters["XmlLocation"].ToString(); //get the location of the XML file and parse
  string lib = path.Substring(0, path.LastIndexOf("/"));
  string formName = path.Substring(path.LastIndexOf("/") + 1);
  using (SPSite site = new SPSite(SPContext.Current.Site.ID))
  {
   SPWeb web = site.OpenWeb(SPContext.Current.Web.ID); //grab the current web
   SPListItem li = web.GetListItem(path.Replace(web.Url, "")); //grab the current list item using the

   if (li.DoesUserHavePermissions(SPBasePermissions.EditListItems)) //check for permissions
    SetNodeValue("/my:mySAR/my:IsReadOnly", "0"); //if it exists, set field to false
   else
    SetNodeValue("/my:mySAR/my:IsReadOnly", "1"); //if it doesn't, set it to true
  }

 }
 else
  SetNodeValue("/my:mySAR/my:IsReadOnly", "0"); //if the XmlLocation doesn't exist, it's a new form so it's not Read Only
}
catch (Exception ex)
{
 WriteErrorToLog("FormEvents_Loading", "Problem setting user permissions", ex);
 SetNodeValue("/my:mySAR/my:IsReadOnly", "1"); //on error stop the user from writing
}

From here I based the buttons' conditional formatting on the field IsReadOnly.

Sometimes if you're performing several stsadm commands (like adding, deploying, upgrading, and/or removing solutions) SharePoint get's some things stuck and it then proves to be a bear to get it out.

For example, we upgraded a solution for a customer using stsadm and we were receiving an error stating we couldn't upgrade the solution. So we removed the solution completely and then tried adding it. We then received an error stating that the feature with this ID already exists. So we went ahead and removed it again and deleted the associated folders from the features folder. Tried to readd it and received the same error. We then changed the id of the feature and then received the error that the folder was already in use by another feature id. Yeah, real fun.

One of the error we received was

The solution can not be deployed.  Directory "FeatureName" associated with feature '90d332d5-e3bc-4eb3-8e7e-4832a6809f5e' in the solution is used by feature 'f59233ef-a1e6-4bf8-b635-8c024a7397b2' installed in the farm. All features must have unique directories to avoid overwriting files.

So even though the feature was not installed, it was acting like it was. I'm guessing it was stuck in the config database. We ran stsadm -o uninstallfeature to remove the feature and that worked! What a bear.

Hope this helps!

The content query web part is a beautiful web part, and it's a shame it's only available in MOSS. I would love to use it in WSS. Anyway, the web part will search the entire site collection, or specific sites as you specify, and return items for certain content types, or all, and/or meeting a filter criteria.

As you can imagine, a very useful tool to roll up data and lists from sites all into a central page or dashboard. The issue with this web part is customizing it! There are a few predefined layouts but nothing that is really helpful. Basically, the web part lists the title, as a link to the item, all of the return results. No other fields are included. If you're interested in adding more fields, it requires some customization.

Fortunatly, there are a few SharePoint gurus out there who were nice enough to share how to customize this web part. Their links are below. I recommend reading through both blogs, though they may be repetitive, they compliment each other very well. Then come back and check out my notes below for some more help.

http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!491.entry

http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx

Further reference from Microsoft

http://msdn.microsoft.com/en-us/library/aa981241(classic).aspx

A Few More Notes

The above references are great, they got me where I am. In my experience:

- I used U2U Caml Builder to get the internal name of the field. Specifically, I was rolling up InfoPath forms, and the internal name was a GUID. By using U2U I pulled the internal name out which was _x0033_11111fc_x002d_d892_x002d_4a7e_x002d_a9bc_x002d_d839ee8ef885.

- I think there might be a name length limitation in the ItemStyle.xsl. In my previous note about the GUID name, I had to use the DataColumnRenames property in the .webpart file to get the column to work. <property name="DataColumnRenames" type="string">_x0033_11111fc_x002d_d892_x002d_4a7e_x002d_a9bc_x002d_d839ee8ef885,OpenDate</property>. I can reference OpenDate in the ItemStyle.xsl file.

-Formatting the above date field is easy enough as well. Add xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" to the header of the stylesheet. Then format the date: <xsl:value-of select="ddwrt:FormatDateTime(string(@OpenDate),1033,'M/d/yyyy h:mm tt')" />.

This one had me for a while until I accidently came across it looking for something else. My big issue was that the SharePoint pages were all laid out quite nicely, and pretty. Title and description on the left and the controls on the right in that neat blue. I recreated this layout manually: table, row, cell, span for the title, span for the description, next cell, class for the blue background, span for the label, user control, next row... and so on.

There are lovely user controls available: InputFormSection and InputFormControl. Using these user controls, these neat SharePoint formatted pages are a whiz to make! Instead of me reinventing the wheel, check out http://karinebosch.wordpress.com/sharepoint-controls/inputformsectionascx-control/ for a more details. Well worth it!