Export a Dataview as part of a Site Template

Out of the box, if you use a list-bound dataview as part of a Sharepoint Site Template, you’ll get a grumpy message when creating a new site

“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.”

How helpful.

The issue is the dataview has a hard-coded reference to the list guid on the original site. To resolve this, simply wrap curly braces “{” and “}” around all instances of the guid. This tells Sharepoint to refer to the newly created list when deploying the site template.

Granted this seems like a bug, but it works.

There should be 6 or 7 references to the listID in any dataview. Just hunt through the code and you should find it fairly easily.

By admin on October 21, 2008 | Sharepoint | A comment?

AJAX-Enabled Web-Parts: solving the problem of changing Client IDs

AJAX-Enabled Web-Parts: solving the problem of changing Client IDs One of the most challenging aspects of building SharePoint-enabled web parts is using JavaScript to interact with specific controls. As a consequence of how SharePoint renders controls with id’s in Sharepoint WebParts, it’s near impossible to write clean JavaScript. From a maintenance perspective I HATE using server-side code to render JavaScript. It’s inelegant and reeks of a lack of forethought. Yuck yuck yuck. It’s like sweeping dust under the rug. Wherever possible, webpart-specific javascript should be held within a single .js file (stored in the 12Hive). The problem is that Sharepoint alters a control’s ID during the page rendering process. So, a label with the ID “label1” might become “ctl00_label1”. The naming process is entirely unpredictable. This makes interacting with a specific DIV, INPUT or any other html element very difficult because you can’t predict the rendered IDs during development. This is especially problematic if you’re looking to host several instances of a webpart on a single page. One really terrible way of dealing with this is to render the html yourself by adding literal controls ala

LiteralControl l = new LiteralControl();
l.text = '
'; this.Controls.Add(l);

This is a terrible approach which is severely limiting and unnecessary. To tackle the problem I’ve devised the following solution which revolves around creating a Javascript class to accompany the web part:

  • create properties to store the dynamically generated IDs of every html component to wish to interact with
  • create pointers to every html component you wish to interact with
  • create an init function. As input you pass the clientID of the webpart AND the id’s of every component you wish to interact with.
  • this function will store the id’s using the properties
  • this function will also attach the pointers to their respective objects
  • this function should also attach any eventhandlers
  • create any supporting functions (i.e. webservice calls, webservice receivers)

This approach embraces the absence of reliable identification info. It is also sympathetic to having multiple copies of a webpart on the same page. Here’s what the javascript might look like

function UpdatingLabelWebPart() 

	var me = this;	//required to reference the object at runtime  
	this.clientID = null;	//ids 
	this.labelID = null; 
	this.buttonID = null;
	this.label = null;	//controls 
	this.button = null;
	this.register = function (clientID, labelID, buttonID) 
		me.clientID = clientID; //init the id 
		me.labelID = labelID;
		me.buttonID = buttonID;
	this.attachToButton = function() 
		//if the controls haven't loaded yet 
		if (document.getElementById(me.buttonID) == null || document.getElementById(me.labelID) == null) 
			setTimeout(me.attachToButton, 50);
			//register the controls 
			me.label = document.getElementById(me.labelID);
			me.button = document.getElementById(me.buttonID);
			//attach any events button.AttachEvent("click", me.buttonClicked);
	this.buttonClicked = function(sender, args) 
		me.label.innerHTML = "Hello World";

This approach lets you have multiple instances of the same AJAX-enabled webpart and saves you the hassle of having to write annoying javascript (having to write me.label is hardly a chore).

By admin on September 16, 2008 | Ajax, ASP.NET, c#, Mac, Sharepoint | A comment?

SharePoint 2007 and WSS 3.0 Dispose Patterns by Example

Just came across a very helpful post on Roger Lamb’s Blog which provides a number of examples on how to properly dispose of objects within the Sharepoint object model. One specific piece which was very useful was:

By admin on May 26, 2008 | c#, Sharepoint | A comment?

Changing how a web part displays while in edit mode

There are a number of circumstances where you might want a web part to display differently depending upon the display mode of the page.

For example:

  • you might want to provide detailed instructions to the user while in edit mode (or connections mode, etc.);
  • the scriptaculous & prototype libraries conflict with Sharepoint javascript while in edit mode, causing a range of javascript errors;
  • you might want to provide a more rich user interface than Editor parts allow.

To do so, is quite simple in concept, just identify the display mode, and chuck an “if” statement in there. However, it did take me a while to find the right code and I thought it was worth posting about, especially because it can help you give users a more professional & polished interface.

First, where I looked for the display mode. There’s a WebPartManager class which exists, and has a display mode, but it’s tricky to find an instance.

If while inside CreateChildControls or OnPreRender you try:

WebPartDisplayMode currentMode = this.WebPartManager.DisplayMode;

you will get a null pointer exception, because this.WebPartManager == null. I don’t understand why, but it does.

What you need to do is execute the static GetCurrentWebPartManager function on your current page object (found this from a post by Rich from

WebPartManager wpm = WebPartManager.GetCurrentWebPartManager(this.Page);

if (!wpm.DisplayMode.AllowPageDesign)
this.Controls.Add(new Literal(“browse mode”));
this.Controls.Add(new Literal(“not browse mode”));

This relies on the boolean AllowPageDesign property. If true, the page is in edit mode (that includes the edit, connect, design & catalog modes). It’s definitely a bit silly that this.WebPartManager doesn’t work, especially because it’s such a simple property to implement. Maybe somebody can fill me in on the history?

By admin on May 20, 2008 | c#, Development, Sharepoint, webparts | A comment?

Dataview web parts in your master page cause errors on subsites

If you’ve had this problem, then two things to make you feel better:

  1. The solution is very easy
  2. The cause of the problem is stupid stupid stupid. You can bang your head against the keyboard, there’s no way you could have known.

This post, meanders a bit, so if you want the solution, jump to the bottom.

Still here? Sucker.

So, what are the prerequisites to causing this problem:

  • you have a dataview web part inserted into a master page;
  • the dataview refers to data in a list; and
  • the list is scoped at the root web of the site collection.

I think that’s it.


The web part will display correctly anywhere in your root web, but nowhere else. I’m calling it a “web” here because it maps to how Sharepoint’s API. If it helps for you to think about it as a single “Site” in WSS2.0 fashion, go nuts. When you visit subsites, you see the following error:

“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.”

How helpful, especially if you’re an administrator or developer. As if they’d have a magic wand to fix the problem. The error might as well say:

“You’re screwed. Unless you’re a clever developer, give up, swear at Sharepoint and call tech support. Not many people at your company are going to be able to help you.”

Which is silly, because once we come to the cause, the error is completely within the realms of detection. To the developer who wrote that line of code… 10 minutes on the naughty step.

The problem is seemingly unresolveable. If you try to add the dataview directly to a page in a subsite, it works fine, but master page? Sharepoint tells you to go whistle.


The cause? Sharepoint doesn’t know which “web” the list comes from.

The Dataview web part can take parameters, including, parameters which tell pages where to find a list. In Sharepoint Designer, when you edit a master page, it fails to insert a parameter telling pages the list lives in the root.

Bad Sharepoint Designer! Bad!

The problem compounded because taking a dataview created on a subsite and dumping the code into the masterpage doesn’t work either (which makes it very tricky to solve).

To figure this out, I took the following steps in Sharepoint Designer:

  • Created a dataview in the master page (worked at top level and nowhere else)
  • Created the dataview with the exact same settings on a page in a subsite
  • Copied the code snippets into a text-editor and compared them side-by-side

A side-by-side comparison revealed several things…

Web part parameters in the master

Web part parameters in a page

First, the datasource control (a child of the dataview web part) is referred to with a different namespace in the master page than in the page itself. This is why you can’t copy dataview code from a regular page into a master page. Maybe there’s a good reason for having done this, but I think the masterpage programmer forgot to speak to the regular page programmer. However, that isn’t the root cause, but something to be aware of.

Second, THERE’S ANOTHER PARAMETER. OMG!!! Froth, swear, stomp, swear, slam your keyboard. Feel better?

Knowing a parameter exists and knowing the syntax are two different things. Before finding the actual code, I was pretty confident the problem was down to subsites not knowing where the list was.

The worst thing is that the url of the web is actually part of the dataview web part, down at the very bottom of the code. Why doesn’t this flow through to the datasource? Naughty step!

Web part parameters


It’s simple enough to copy the parameter from the subsite dataview into the masterpage dataview.

<WebPartPages:DataFormParameter Name=”WebURL” ParameterKey=”WebURL” PropertyName=”ParameterValues” DefaultValue=”/”/>

I don’t believe the approach is necessary if you’re referring to a list in a subsite (the parameter should be inserted automatically).

Hope that helps!

Getting your controls to appear in Sharepoint Designer Toolbox

The guy over at has posted a v. handy little note about how to get your a servers control into the toolbox in Sharepoint Designer.

Apart from registering your control within the SafeControls part of the web.config), the secret sauce is to add :

[ToolboxData(“<{0}:ControlName runat=server />”)]

to your class (just above the class declaration)


[assembly: TagPrefix(“yournamespace”, “selected prefix”)]

What then happens when you drag the control into designer is that it inserts

<prefix:ControlName runat=server /> into the page.

By admin on April 28, 2008 | c#, Development, Sharepoint | A comment?

Personalizable attribute of web part properties

Why does everything Sharepoint require a trip to Google? Oh well.

If you’re trying to make a web part property editable you need two attributes, Personalizable and WebBrowsable.

You need the WebBrowsable property in order to see the property via the web interface in Sharepoint.

You need the Personalizable propetry to be able to edit it.

However, Personalizable sounds like it’s tied to an individual user (and not all users). Like many things Sharepoint it depends.

Quick answer:

Personalizable(PersonalizationScope.Shared): Single value for all users
Different value for all users

I’m not sure which is default, but according to this it’s the User Scope. Read the msdn article for a more detailed breakdown.

Credit goes to Marco Bellinaso, as I found the reference to the PersonalizationScope on his blog.

By admin on April 27, 2008 | c#, Development, Sharepoint | A comment?

Relative URLs in Sharepoint Web Parts

If you’re using STSDev for web part development, it becomes very simple to deploy files into the 12Hive (which in some circumstances is preferable to using embedded resources). As a consequence, it becomes tricky to create hyperlinks to resource files because:

  • you can’t guarantee the web part is sitting in root of the site collection (which would make for simple hyperlinks ala “_layouts/styles/myPart/myCSS.css”)
  • you can’t know that your site collection is located at the root of the web server (which would make for simply hyperlinks ala “_layouts/styles/myPart/myCSS.css”

So, to create simple relative urls from code (as opposed to using the <% $SPURL:~sitecollection/_layouts/styles/myPart/myCss.css %> approach) I used something I found on Ari Bakker’s website.

Deep underneath the SPContext object is a property called ServerRelativeUrl which is attached to the Site(SPWeb) and Site collection(SPSite) objects.

These can be used by the web part to refer to resource files deployed along with it. So, something like the following should work anywhere inside a site collection:

string cssLocation = SPContext.Current.Site.ServerRelativeUrl + “_layouts/styles/myPart/myCSS.css”;

By admin on April 21, 2008 | ASP.NET, c#, Code, Development, Sharepoint | A comment?

How to fix the “SQLExpress database file auto-creation error” message

I encountered this problem while trying to develop webparts on a my development machine with Sharepoint 2007 (a win2k installation), and found a solution on this page.

Initially the problem occurred because I hadn’t rerun the aspnet_regsql.exe utility. So I did, but I already had SQL Server installed when I setup Visual Studio. As a consequence, SqlExpress wasn’t installed and I used the full-blown SQL install setup with Sharepoint. If you don’t have Sharepoint on your machine, adding the following to your application’s web.config should work just fine:

<add name=”LocalSQLServer” connectionString=”Server=.;Database=aspnetdb;trusted_connection=yes”/>

That got me most of the way, but because I used my SharePoint install, the ASP.NET databse went onto #YourServername#\OFFICESERVERS.

To resolve this you need to change the string to.

<add name=”LocalSQLServer” connectionString=”Server=#YourServerName#\OFFICESERVERS;Database=aspnetdb;trusted_connection=yes”/>


By admin on April 19, 2008 | c#, Sharepoint | A comment?

Broken intellisense when working with Microsoft Sharepoint

I have to say, getting up to speed with WSS/MOSS programming is rather difficult after four years of having nothing but javascript and vba.

One thing that’s is evident is that Intellisense is vital to being productive. It’s just far too slow to develop without it.

So when Intellisense died in VS2005, I got grumpy. It wasn’t totally dead, just mostly dead. It would still give me references to strings and stuff, but the entire Microsoft.Sharepoint library was Intellisense free.

I eventually found a solution on my own, although I won’t claim to understand it.

in the 12 Hive there’s a file called Microsoft.Sharepoint.xml, which seems to contain the Intellisense definitions. All you need to do is “touch” it (i.e. change the file modification date), restart Visual Studio, and Intellisense springs back to life.

The file is under the ISAPI folder. Take a backup obviously.

I did try two other things which may or may not have helped.

I cleared out all the files in:

C:\Documents and Settings\Administrator\Application Data\Microsoft\VisualStudio\8.0\ReflectedSchemas

which is apparently the Intellisense cache. I did this before playing with Microsoft.Sharepoint.xml, but only had a little joy (a few more things came back but nothing in Microsoft.Sharepoint).

I also removed the Microsoft.Sharepoint.dll and added it back in, but can’t tell if it helped or not.

By admin on April 16, 2008 | c#, Development, Sharepoint | A comment?