Posts Tagged ‘SharePoint Development’

How to learn SharePoint

Date:January 24th, 2013 Author: Tags:
Category: General, Training Comments:0 ;

SharePoint is a HUGE product. Add to that the Microsoft upgrade treadmill (e.g. SharePoint 2013) and even though I’ve been working with it for nearly 8 years now I am still finding new things.

Perhaps the most common question you see in forums (StackExchange, Microsoft Community Groups, Linked In groups or plenty of other places is “How do I learn SharePoint?”. And this isn’t just restricted to Developers – its power users, end users and everyone else in the spectrum. And its not just individuals – as Veronique eloquently points out – many companies install SharePoint and then… then… wonder “We’ve got SharePoint, Now What?”.

So where do you start? Some would argue that depends if you’re a developer, power users, user or admin – and whilst that’s true to some extent if you’re a developer you really need a good grounding otherwise you will spend days recreating something that’s already built in if only you knew it existed! If you’re an administrator how are you going to set policies for something you don’t know inside-out?

Mark at Collaboris has put together some lists of resources using that you can vote on using a cool service called As votes are cast the best content should surface to the top – How to learn SharePoint and where to get training.

In addition to that if you’re a developer you obviously need to start with a solid grounding in ASP.NET. After that you are not short of places to start but two that spring to mind are Bjorns (who never afraid to be opinionated!) – What is a SharePoint developer post and Stuarts 10 things developers should know about SharePoint

Check out this list of SharePoint resources and vote for your favourites!

SharePoint Sandbox Solutions: The Good, The Bad, and The Ugly

Date:July 11th, 2012 Author: Tags: , , , ,
Category: General, SharePoint Development, SharePoint webparts, Training Comments:3 ;

Sandbox solutions are often seen as the cure-all for the worries of installing in-house or third party software on your SharePoint farm; but all is not as it seems.

This article aims to dispel some of the illusions around the safety of Sandbox Solutions, and cut through some of the fluff about what the sandbox should actually be used for and why.

  • The Good: What sandbox solutions do well
  • The Bad: What sandbox solutions don’t protect you from
  • The Ugly: The compromises you have to make to use them

What is a Sandbox Solution?

A Sandbox Solution is just like a normal Farm solution, except that it is deployed to a specific Site Collection (rather than the whole Farm), and has a limited set of tools it can use.

A full listing of what you can and can’t do in the sandbox can be found here:

Sandbox Solution Considerations (section “Capabilities and Elements in Sandboxed Solutions”)
Restrictions on Sandboxed Solutions in SharePoint 2010

It’s just like having a toddler in a sandbox in your garden (or yard): They can build sandcastles and dig holes using the tools you give them, but they can’t play with the chainsaw or ride-on mower you’ve left lying around (or dig enormous holes in your flower beds).

The Good

Sandbox Solutions are prevented from doing many things that could cause security or performance issues on your SharePoint server. Notable restrictions include:

  • No access to the network(s) your server is connected to
  • No access to the server’s registry
  • No access to the server’s filesystem
  • No access to e-mail via SMTP
  • Permissions cannot be elevated

There are also some additional features to help keep solutions in line:

  • Solutions can be installed at the Site Collection level by Site Collection administrators.
  • Resource Usage Limits are applied to solutions and can be monitored and limited by the administrator, preventing faulty or processor-hungry code from overwhelming the server.
  • Solutions can be automatically validated, and known troublemakers can be banned from the entire farm.

Notably, the main benefit to the Site Collection administrator is the ability to deploy their own solutions, but the majority of the other benefits are to the Farm administrator (and/or hosting company); although everyone benefits from the improved system stability these features help to ensure.

The Bad

There are a great many features to help with system stability and the prevention of security breaches; but there are limits to what the solutions are prevented from doing.

You should certainly never deploy untested third-party solutions to the sandbox “without fear of bringing down the entire farm”.

The best example of a danger to stability from within the sandbox is the lack of control over the Client Object Model, mentioned here: Sandboxed Solutions in SharePoint 2010

Pages, Web Parts, and controls that are deployed in sandboxed solutions can include code that runs against one of the SharePoint Foundation client-side object models … Code that runs on the client computer is not subject to any of the code execution or resource usage restrictions.

For example, a solution could contain malicious or badly written code executed via COM that requested all the items in a list an infinite number of times. If embedded into a web part, this would effectively turn the computer of every user that viewed it into a node of a DDoS attack on the server farm.

Rather less dramatically, it’s worth noting that there are no specific restrictions on actively malicious code within a Site Collection. It’s perfectly possible to:

  • Delete sites and sub-sites
  • Add COM calls to export data to an external site (much like Wictor’s data import)
  • Copy data added/edited in lists with item-levels permissions to unrestricted lists

The Ugly

Although sandboxing adds restrictions at every level of SharePoint, the feature wasn’t in the original platform design (in SharePoint 2007). In order to squeeze this feature in, some sacrifices had to be made.

Since there’s no access to the filesystem, the following aren’t possible:

  • Application Pages
  • Visual Web Parts (since they deploy a Control Template)

There are a some compromises due to Split Page Rendering; where sandboxed web parts are rendered separately from the rest of the page in a controlled thread:

  • No Script Manager to output/organise JavaScript
  • No web part connections
  • No access to the page Cache

Similar to the above: Because sandbox solution code needs to run in a controlled thread, the following functionality (that uses separate threads) had to be removed:

  • Workflows containing code
  • Timer jobs

Although most of these compromises are understandable, there are some features that are missing for no apparent reason:

  • You cannot use any of SharePoint’s own web controls (e.g. Date picker, User selection)
  • You cannot hide Custom Actions, or add Custom Action Groups


Sandboxing makes it less likely that you’ll accidentally destabilize a SharePoint farm with broken code, and make it easier to find and deal with trouble making solutions.

It’s also more difficult for malicious code to gain access to anything outside the Site Collection it’s deployed to, and slightly more difficult to destabilize the farm.

However, it doesn’t guarantee safety from either bad or malicious code and there are a large number of compromises to consider. Working around sandbox limitations will add overheads to most development projects, and many solutions will simply not fit into the sandbox model.

For example: FilterPoint and Highlighter are two of our own products that can never be made sandboxable, as they’re based on features that are simply not available in the sandbox.

Edit: Since the publishing of this post, we’ve discovered that sandbox solutions are now deprecated in SharePoint 15; as mentioned in the article SharePoint 2013 preview – Apps or Crapps?.

10 things developers should know about SharePoint

Date:May 4th, 2012 Author: Tags: , , , ,
Category: Community, General, SharePoint Development, Training Comments:1 ;

Many developers walk into the world of SharePoint unaware of the strange and interesting journey of discovery they’re about to begin.

It’s often difficult to know where to being, so here’s the top 10 most useful things I’ve learned since I joined Pentalogic back in 2010.


1. Know your Editions
2. Don’t even look at the database
3. Get to know the front-end
4. Dispose of your disposables

Building your Knowledge

5. Learn the language
6. Get a good book
7. Love the MSDN documentation
8. Find a SharePoint community that suits you

General advice

9. Learn to live with CAML
10. Remember that SharePoint is enormous

1. Know your Editions

SharePoint comes in many flavours, each of which has it’s own features and shortcomings. Here’s a quick run down of the notable versions:

Release Cheap Expensive MS Hosted
2010 Foundation Standard/Enterprise SharePoint Online
/ Office 365

It’s useful to get to know these for when you’re searching for solutions, as you’ll sometimes come across those that are edition specific (e.g. the Standard Edition’s ContentIterator class for querying large lists).

There are few things more frustrating than finding the perfect solution, and then discovering you have the wrong Edition.

2. Don’t even look at the database

To those new to SharePoint this is entirely baffling: Why wouldn’t you want to get data from the database? There are two good reasons for this:

a) Microsoft is very touchy about their database. They will not support any installation with software on it that modifies the SharePoint database.

b) The structure will give you nightmares. At some point in almost every database developer’s career they say: “Why don’t we abstract the table structure, and just have one massive generic table of text data?”

They’re then hit in the head by whatever small throwable object happened to be nearby, and their colleagues point out that although it would be very flexible, it would also be fantastically slow and unwieldy.

Unfortunately either the SharePoint team operated a clean desk policy, or they put an extraordinary value on flexibility, and the result is lurking in the darkness of the SharePoint database.

3. Get to know the front-end

It’s very tempting to dive straight into the code side of things, but when you’re trying to orientate yourself in the API it helps to have a good understanding of what you’re looking at from the front-end.

It’ll also give you a good feel for the site’s design, and hence what sort of layout the users will expect to see.

Many of the actions you perform in code will correlate to actions in the front-end, as well as the structure.

For example, to find a particular list’s view in the front-end, you would:

  • Open the site using the URL
  • Open the sub site
  • Select the list
  • Select the view

The code version of which is very similar in structure and information needed:

    using (SPSite site = new SPSite(http://site))
         using (SPWeb web = site.OpenWeb("subsite"))
             SPList list = web.Lists["List name"];
             SPView view = list.Views["View name"];

4. Dispose of your disposables

Some SharePoint objects (in particular SPWeb and SPSite) won’t automatically dispose of themselves when they’re no longer used. If you’re unaware of this, then you may easily run into post-deployment problems caused by the ensuing memory leaks.

The code in the previous section shows one method of dealing with this problem, and here is Microsoft’s advice on the subject: Disposing Objects

Interestingly, you shouldn’t always dispose of these objects; for example you shouldn’t dispose of  SPContext.Current.Web. As a general rule of thumb:

If you made it, dispose of it. If you were given it, leave it.

5. Learn the language

There is a huge amount of SharePoint-specific terminology, and some of it can be inconsistent and often misleading. For example, a Site Collection is an SPSite object, but a Site is an SPWeb object.

Another example that caught me off guard at first was that there’s a difference between the Object Model (the server-side SharePoint API) and the Client Object Model (client-side API). Whereas I was under the impression that one was an abbreviated form of the other.

Microsoft has published an enormous glossary, which seems to cover quite a lot of it: Glossary for SharePoint 2010. Although as with any jargon or language, most of it is learned along the way.

6. Get a good book

A good reference guide is infinitely more useful than an enormous glossary when getting to know the components of SharePoint. It’s vitally important that you get an overview of all of these components, to avoid inadvertently reinventing the wheel.

There are two I can personally recommend (having read them both cover-to-cover):

Building the SharePoint User Experience (Furuknap): Written for 2007, but still covers the mainstay of SharePoint. An easy and interesting read: If you’re quickly bored by dry textbooks, then this is definitely the book for you.

Inside Microsoft SharePoint 2010 (Various): A good follow-on from Furuknap’s book. A solid foundation of 2010 knowledge, and a good one to refer to now and again. Don’t start with this book though, or you’ll find yourself climbing a pretty steep cliff.

As your SharePoint knowledge grows, revisiting the books can also be quite useful. Parts you may have glossed over previously will suddenly start to make more sense, and you may find some useful tips you missed first time.

7. Love the MSDN documentation

Having developed and worked with a great many third party APIs and interfaces in the past, I can say with considerable confidence that the MSDN documentation is phenomenal.

Every class, method, and property is documented. Even the most obscure properties have at least a placeholder page, which in itself offers more information than many specifications. On top of this is the community comments on each page add clarification and often links to useful related articles.

However, there are two minor shortcomings. The first is that the background documentation (such as “Disposing Objects” mentioned above) is usually painfully boring to read and often skims around subjects rather than getting to the point.

The second is that the CAML documentation is very bizarrely structured: Elements used for almost completed different things share the same page just because they have the same name. There is also missing documentation where the CAML is more obscure, such as the elements used in SPWeb.ProcessBatchData().

8. Find a SharePoint community that suits you

Sometimes no amount of Googling or searching of MSDN’s documentation will find you the answer to the problem that’s been bugging you. In these circumstances it’s good to have a community of like-minded SharePoint developers to help you with your problem.

Being an active member of a community will also help you to expand your knowledge of SharePoint in general.

Here are a couple of the more notable SharePoint developer-friendly communities:

I’ve previously discussed the differences between the two in the following article: SharePoint Questions: MSDN versus Stack Exchange

9. Learn to live with CAML

Collaborative Application Markup Language (CAML) is another example where flexibility seemed to take precedence over usability. In certain circumstances you’ll be forced to write unserializable and poorly validated XML to perform seemingly simple tasks, such as importing comparatively small quantities of data (a few thousand rows).

However, it isn’t all bad: As I mentioned, CAML does allow a great deal of flexibility, and also has very easily readable syntax. The core resource for CAML can be found here: Collaborative Application Markup Language Core Schemas

When querying data you can avoid CAML by using LINQ, which is reputedly faster and easier to use. If you have no fear of CAML (or are working on 2007), the following tool may be of use to you: U2U CAML Query Builder

P.S. While we’re talking about tools, I should mention the extensive and impressive list of SharePoint development tools found here: List of SharePoint 2007 development tools

10. Remember that SharePoint is enormous

It’s important to bear in mind that SharePoint is a mind bogglingly large framework, with dark corners that even the SharePoint Development Team themselves haven’t visited in years.

This is important because occasionally you’ll find an area that’s poorly documented or has strange known issues, and it helps to have a little perspective on the scale of the system you’re dealing with.

You also need to be aware that there’s an awful lot you don’t know, and some of which you may never know. Getting a good overview of the components is essential. I wouldn’t recommend designing a project to use a component (such as a Custom Field Type or Site Template) until you’ve at least made a prototype in that area; to appreciate the depth of what you’re tackling.

The variety of customizable components in SharePoint also means that there is almost always more than one solution to a problem, as you can see in some of my previous posts: How to do list highlighting in SharePoint


The first challenge in SharePoint is discovering the existence of all the things you don’t understand yet. Once you’ve got a vague idea of all the different components, then you can really start to learn what each is about.

To borrow Mr Rumsfeld’s turn of phrase: Once all your unknown unknowns are known unknowns, you can start learning known knowns.

How not to develop a SharePoint [Today] Calculated column

Date:August 22nd, 2011 Author: Tags: , ,
Category: Calculated Columns, Highlighter, Training Comments:4 ;

After developing SharePoint Highlighter, we seriously considered expanding on this area with a Calculated Column that would allow you to use [Today] in the formula. If you’re thinking “But you can already!” I suggest looking at Ryan’s article about the [Today] column trick.

Needless to say, this would be a very useful tool for almost any SharePoint user. After much researching and prototyping we came to an unfortunate conclusion: Although it was possible to make a Custom Field Type to do this, it was almost certainly impractical (certainly for us).

The avenues we investigated finished in three types of dead-end:

  • Brick wall: A completely impassable system limitation.
  • Overgrown with brambles: Nothing but pain for all involved.
  • Swamps: A long unpleasant slog, with an uncertain outcome.

The Brick Wall

The first thought in any developer’s mind when making a variation on a class should be “Inherit it”. It allows you to take advantage of the existing class’ methods with minimal difficulty and yet offers (almost) total control over its behaviour.

Attempting to do so will reward you with the slightly misleading error:

The type ‘Microsoft.SharePoint.SPFieldCalculated’ has no constructors defined

A brief search in the MSDN documentation for SPFieldCalculated shows that the absence of public constructors is intentional:

Windows SharePoint Services 3.0 does not support inheriting from this class.

And so this avenue ended in a brick wall. More worryingly; disallowing the inheritance of a class is usually a sign that something so heinous is happening inside that Microsoft doesn’t want it reproduced.


Intrigued by the promise of horrifying creatures dwelling within, I had a look inside the class to see what was happening (using my own powers of code intuition, and not any kind of questionable reverse engineering method).

It seems the actual calculations take place outside of the SPFieldCalculated class, using instead a call to SPRequest. This new lane of research quickly ended in spiky brambles, as using a direct call to SPRequest would make our product (and hence anything it’s installed on) unsupported by Microsoft.

Undeterred, I took inspiration from the billing system at my old work and looked at keeping the ‘black box of calculation mystery’ class running in the background, with the new class acting as a wrapper around it.

Creating a Custom Field Type that kept a hidden field for data storage in the background was an architecture we’d experimented with when creating Highlighter, so adding a relatively minor call to update the formula with the current date and time seemed quite easy.

The thorny ending in this case was the enormous potential server load; updating the formula every time the list was viewed (to keep it up to date) caused the entire list’s worth of calculations to be refreshed. Viewing just 20 items would make up to 5000 items recalculate their values for each of our columns on the view.


The final and most desperate option was to do it ourselves: Completely rewrite all or a subset of the calculated column functions, and handle the associated function nesting.

I’m DIM: Doin’ It M’self.

Following this path would mean wading through the boggy and unpleasant process of exactly reproducing Microsoft’s function calls; avoiding the murky bottomless pools of performance issues. All the while hoping we wouldn’t run into any of the hungry and sharp-toothed show stoppers along the way.

As you may have guessed, we didn’t venture down this path.

Why are you telling me all this?

Because although these paths aren’t available to us as an ISV, it doesn’t mean they aren’t options to you (except the brick wall, of course).

Brambles: Using SPRequest is unsupported, but if this doesn’t deter you then this is still very much an option. Similarly, if you have an abundance of processing power (or really need a space heater in your server room) performing complete column recalculations on every view shouldn’t bother you.

Swamps: If you have very specific requirements you could get away with only recoding a few functions, which would greatly reduce the chances of you disappearing forever. Alternatively, if you have a large herd of idle developers you could set about recreating the whole set. However, I doubt this is a serious option for anyone except the head of the Microsoft Silverlight team.

How to create a Countdown in a SharePoint list

Date:May 17th, 2011 Author: Tags: , , , , ,
Category: Highlighter, SharePoint Development, SharePoint Free Tools, Training Comments:0 ;


If you’ve got a list containing important dates (such as the above example), it’s very useful to be able to easily see how long is left before that date, or how long since it has passed. Unfortunately basing a calculated column on the current date isn’t supported by SharePoint natively, as discussed in my previous article: How to use [Today] in a SharePoint list

So how can we work around this shortcoming without having to wave signs and shout outside Microsoft’s offices? The are a few options available to us:

  • JavaScript: Use a Content Editor Web Part.
  • Designer: Create a custom view in SharePoint Designer.
  • Code: Make your own custom field type from scratch.
  • SharePoint Highlighter: Buy our custom field type.

JavaScript document_into83

Since SharePoint is so uncooperative about using the current date on the server side (i.e. with a calculated column), we can wait until the information gets to our browser and fix it there with JavaScript.

We can get JavaScript onto a page using a Content Editor Web Part, which is added just like any other web part. Christophe at Path to SharePoint has put together a script that displays the date difference on hover, that can be modified slightly to display just the countdown: Countdowns – A second method

Adding a CEWP to each page your list is displayed on can become quite arduous if it’s displayed in a lot of places. In addition to this, information in a CEWP is quite vulnerable to accidental edits, as they are accessible to any user that can edit page content.

Designer designer3013

SharePoint Designer is a free and powerful tool from Microsoft for customizing SharePoint. Unfortunately, because it can do so much, its use is often frowned upon by site administrators (and sometimes even banned).

If you’re lucky enough to be allowed to use it, then (in an unusual twist) Christophe may once again be the person to look to. In a break from his many and various JavaScript solutions he’s put together a Designer solution for this problem too: A countdown for tasks lists

As with the JavaScript solution above, the Designer changes will have to be made on each view web part you want to see the countdown on, but fortunately the changes can only be overridden by someone else using Designer, or an administrator.

Code studio63

If you already have the backbone of a custom field type coded, then adding the XSLT to display this in 2010 should be reasonably straightforward. Alternatively this can be done within the custom field type class.

If you’re using 2007, then CAML rendering unfortunately fails you here, and it’s necessary to use a JavaScript workaround in one form or another.

Creating a custom field type from scratch for this sole purpose is probably going to be remarkably costly (in terms of time). Actually making the foundations of a custom field type is a bit of an investment, but thankfully Microsoft has put together a walkthrough to at least help you get started.

The benefit of using this method is that columns created from a field type are displayed on every page without having to add any additional code to the page itself.

SharePoint Highlighter currency_dollar43

Of course, it is possible to get all the benefits of a custom field type with much less pain: Buy a commercial solution.

If you have a glance at out handy product comparison, you can see the wealth of products we managed to find that offer this functionality. So far that grand total is… One: SharePoint Highlighter.

So if you’re looking for a commercial solution it looks like we’re the only option. If you know otherwise then please do tell us; but for the time being we’ll cheerfully carry on being the front-runner in this one horse race.

How to create a SharePoint KPI column

Date:May 12th, 2011 Author: Tags: , , , , , , , ,
Category: Highlighter, SharePoint Development, SharePoint Free Tools Comments:0 ;


Whether you call it a KPI, an Indicator, or a Data Visualization Asset, the chances are that you immediately understand the purpose of the icons in the picture above. The beauty of adding icons to a list is harnessing this instant recognition to make your users work more efficiently with their data.

So how do we add icons to our list? This depends very much on how complex and configurable you want he results to be, so let me give you a run down of the options:

Do It Yourself

  • JavaScript: Do the work on the client-side with a Content Editor Web Part
  • Designer: Customise the list view using SharePoint Designer
  • Download: Download an open source Custom Field Type
  • Code: Create a custom field type from scratch

Buy It

  • Enterprise Edition: Use the Out of The Box Enterprise Edition functionality
  • Buy: Buy a pre-made Custom Field Type

JavaScript document_into8[6]

By adding a Content Editor Web Part to each page you want the icon to display on, you can add JavaScript that will insert icons once the page has been rendered.

Christophe at Path to SharePoint uses his signature HTML Calculated Column to do most of the hard work in his article: Apply color coding to your SharePoint lists. In this instance JavaScript is used solely to render the HTML correctly, as SharePoint renders the output of calculated columns as text normally.

Designer designer30

If you don’t mind spending a little time dabbling with SharePoint Designer, and you can convince your Site Administrator you’re probably not going to do anything too damaging; then Microsoft’s free tool may be the solution for you.

Toni Frankola has risked the wrath of Microsoft and written an article on how to use Designer reproduce Enterprise edition’s KPI columns without having to upgrade: Visual Indicators for the Masses: KPIs in WSS.

As with the JavaScript solution, you’ll have to make this change on every page you want to see the icons on.

Download arrow_down_green4

If you’re and end-user looking for a quick solution, or a developer interested in further developing an existing Custom Field Type, then the IconSet CodePlex project may be of interest to you.

I have enormous respect for those that donate their efforts to the community, such as the developers of this project. Unfortunately open source developers often have a day job and other commitments, so expecting rapid free support from them can be a tall order.

Code studio6

It’s entirely possible to create a Custom Field Type yourself. This is by far the most time-consuming of the options listed on this page, and hence also probably one of the most expensive. However, if you want to avoid some of the initial investment, you could use the IconSet CodePlex project mentioned above as a good starting point (or reference guide).

Fortunately, as the icons are directly rendered onto the page you can avoid the majority of the JavaScript rendering problems I mentioned in How to do list highlighting in SharePoint. If you also avoid [Today] then you can avoid some of the related trouble.

A benefit of all three of the Custom Field Type options is that the results are shown wherever the column is shown in a view, avoiding page-by-page additions.

Enterprise Edition sharepoint

SharePoint Enterprise edition allows you to add KPI information to your site, along with many other additional features. If you’re working with Enterprise edition then take a look at Mark Miller’s article: KPIs for the Masses.

Since use of this functionality is prolific and directly supported by Microsoft it’s very a good option for those that have this version of SharePoint. Unfortunately the functionality isn’t available to those working with Foundation or Standard edition.

Buy currency_dollar4

Many companies don’t have Enterprise edition, and feel that upgrading solely to use the KPI functionality is perhaps not the best use of resources. As a result, the functionality has been reproduced by a great many products (not least our own: SharePoint Highlighter).

Because we have our own product in this area, we’ve created a product comparison to demonstrate the available functionality, and associated cost.

How to do list highlighting in SharePoint

Date:May 11th, 2011 Author: Tags: , , , , , ,
Category: Highlighter, SharePoint Development, SharePoint Free Tools Comments:1 ;


Lists can often look a little bland, and attempting to impatiently skim read them can often lead to missing important information. This is why a bit of well-placed color can really help users with their day-to-day work.

In my last post How to create a progress bar in SharePoint I covered the various methods of displaying a progress bar on your SharePoint list view. For this article I’m going to do the same for row and cell highlighting, as I’ve spent a rather considerable time wrestling with this particular feature in SharePoint Highlighter:

Client based

  • JavaScript: Put some JavaScript code into a Content Editor Web Part
  • Designer: Use SharePoint Designer to set up Conditional Formatting

Custom Field Type

  • Code it yourself: Make your own custom field type from scratch
  • Buy: Purchase a pre-made solution

JavaScript document_into8

If you need a free solution that doesn’t require farm administrator permissions, then using JavaScript in a Content Editor Web Part may be the solution for you. As always with this method, Christophe at Path to SharePoint has a great example.

Alternatively, there’s a slightly off-topic walkthrough by Boris Gomiunik which avoids having to use an HTML calculated column. It has a great deal of useful information, and would only require minor tweaking to do cell or row coloring instead of text.

The JavaScript and CEWP method should avoid having to trouble your IT department to make the change, which I’m almost certain you’ll both be happy about.

Although you’ll have to implement the CEWP on every page you want the highlighting to display (which may cause your view drop-down to disappear), you may not have to copy the full JavaScript into every CEWP, as discussed in my previous article’s comments.

Designer designer30

If you’re lucky enough to have a generous (or inattentive) IT department, you may be able to use SharePoint Designer; a free tool from Microsoft. SharePoint Designer allows you to add Conditional Formatting to your list views in a manner very similar to Excel. This has to be added to each of the views you want to see the highlighting on.

You’ll need a little time to become familiar with Designer, and to set it up for your needs, but once you have done so it can be a powerful tool. Unfortunately it is often regarded by administrators as a dangerous tool for this very reason.

There’s a useful step-by-step guide to setting up conditional formatting in SPD 2010 by Frederique Harmsze at Macaw, and a more straight-laced 2007 version on the Microsoft Office site.

Code studio6

Creating a custom field type to perform highlighting on a list view is in many ways like trying to type on a keyboard on the other side of a crowded the room with a pole (which sometimes gets stolen by the janitor if you leave it out overnight). That might be a slight exaggeration, but it is very awkward.

This is mostly because there is no way to programmatically interact with the row and cell color from server-side code (the distance across the room in my analogy). So you’ll need to get JavaScript onto the page in order to do the highlighting (the metaphorical pole).

The crowd represents SharePoint’s own JavaScript (all 0.5MB of it), which may interfere with yours; an example of this would be the use of AJAX to render Group By views.

Finally, SharePoint seems to passive-aggressively object to script elements, and silently removes them from HTML text stored in the database; the metaphorical janitor. This can be worked around by rendering using XSL (in 2010) or CAML (in 2007).

Buy currency_dollar4

If you want to avoid the unpredictable cost of time spent creating a solution, then you’re better off paying the money up front for a pre-made solution. As a bonus it won’t be you that has to test it to death or maintain and support it.

By some enormous coincidence, we happen to have recently released a product called SharePoint Highlighter that can do this kind of highlighting very easily. Of course, there are other similar products on the market, which we’ve listed on this handy comparison matrix.

How to create progress bars in SharePoint

Date:May 10th, 2011 Author: Tags: , , , ,
Category: Highlighter, SharePoint Development, SharePoint Free Tools Comments:7 ;


Progress bars are a great addition to any list; making percentage values, target achievement, and progress between dates much clearer. Having included this functionality in SharePoint Highlighter, I’ve tried and tested the various ways this can be achieved and thought I’d share my conclusions.

The main methods for getting a progress bar on your list are:

Client based

  • JavaScript: Put some JavaScript code into a Content Editor Web Part
  • Designer: Use SharePoint Designer to create a custom view

Custom Field Type

  • Free Download: Install a community-supported custom field type
  • Code it yourself: Make your own custom field type from scratch
  • Buy: Purchase a pre-made solution

JavaScript document_into

If you need a free solution that doesn’t require farm administrator permissions, then Christophe’s JavaScript progress bar may be what you’re looking for. This uses JavaScript in a Content Editor Web Part along with a calculated column to render the progress bar.

To customise this to suit your needs you need to have some experience with JavaScript. Alternatively, Christophe is very quick to respond to comments, and may be willing to help with minor tweaks or troubleshooting.

Advantages of this method are the flexibility of Christophe’s HTML calculated column, and the low cost (providing you don’t spend too long customising it). Although by far the largest advantage is that most end users will be able to implement this solution without having to contact their IT department.

The main disadvantage is having to implement the CEWP on every page you want to see the progress bar, and the need to change the JavaScript in every CEWP for any future alterations.

Designer designer

If you’re reasonably familiar with SharePoint Designer, or you’re willing to learn a little, then the Microsoft SharePoint Designer Team Blog has a good article on how to use it to create progress bars: CSS Style Bar Graphs using Data Views

The main advantage of this solution is that it is free (SharePoint Designer is a free download), not counting the cost of the time to create it of course. As with the JavaScript solution, you will need to add the modification on each page you want the progress bars to be displayed.

SharePoint Designer has a chequered history with regards to the amount of power it wields (and hence damage it can cause), and so it is unfortunately often the case that SharePoint site administrators ban or severely restrict its use.

Free Download arrow_down_green

If your requirements are quite straightforward, there are a few community supported progress bar custom columns available for download (for example this Codeplex project).

These are single-purpose additions that tend to be low on customizable options (such as conditional formatting), but are good for quickly meeting specific requirements.

These community supported progress bars are usually open source, which allows you to further develop them if you wish. The above example is an exception; being both closed-source and obfuscated. Support for community projects is unfortunately entirely voluntary, and usually forum-based.

Code studio

If you’re reading this section rather than trying to ignore it you’re probably a developer, or thinking about hiring one. I can tell you from experience that unless you have some very specific requirements or intend to re-use the code for other solutions, it will almost certainly be cheaper to buy a pre-made solution.

This is for the most part due to the rather large overhead of setting up the infrastructure of a working custom field type and the daunting learning curve associated with it. For the sole purpose of creating a progress bar, this investment of time may be disproportionately expensive.

Obviously having a vested interest in you buying our product makes my advice somewhat tainted, so I’ll refer you to the impartial words of Bjørn Furuknap on the subject:

“Looking back I think it would have been easier, and less painful, to eat my own eyes.”

If you’re brave enough to continue down this path, creating your own custom field type allows you to tailor a solution much closer to your needs, limited only by your determination and ability to think sideways. To help you on your way, there is a particularly useful MSDN walkthrough.

Although MSDN as a whole is a gold mine for such a project, there are some rather troublesome areas that are thinly documented.

Buy currency_dollar

There are a number of commercial products on the market that allow you to add visual indicators such as progress bars to lists; one in particular that springs to mind (for some reason) is our own product SharePoint Highlighter.

Many commercial solutions come with additional features that may make the purchase more worthwhile. Rather than throw marketing bullet points everywhere (Synergise ROI!) I’ll simply nod meaningfully towards this comparison matrix.

Enormous professional bias aside, the main benefits of a commercial solution in comparison to the above alternatives are: guaranteed support, more reliability, and user-friendlier configuration. Of course, the glaring disadvantage is having to spend some money up front, rather than the less visible cost of time.

Conclusion about

Each of these possible solutions caters to a slightly different problem, and there is no single right answer. Obviously if there was a single correct, reliable, unbiased answer it would be to buy SharePoint Highlighter*.

*Possibly not entirely unbiased

Editing The SharePoint List Item Menu (Part 3: Other Uses)

Date:November 18th, 2010 Author: Tags: , , , , ,
Category: General, SharePoint Development, SharePoint Ideas, Training Comments:4 ;

In previous posts I’ve used the “Open in new window” function to illustrate the two different methods of adding to the List Item menu, or Edit Control Block (ECB) to use its catchier name.

Part 1 covered the CustomAction element; the developer-leaning Visual Studio method. Part 2 avoided any kind of dedicated program by doing the same directly in SharePoint using Javascript in a Content Editor Web Part (CEWP); for power users or those with software commitment issues.

In this section I’ll be looking at some more interesting, and possibly useful, extra options to illustrate the potential of these kinds of enhancements. These can also be used as stubs to produce more complex functionality along the same lines.

I’ve purposefully kept these changes low-touch (avoiding AJAX libraries for example), to make them quick to try out without installing any additional dependencies.

In each example I’ll give a snippet of code for using a CustomAction or Javascript; these will be brief, as they assume you’ve read my earlier posts.

E-mail a task

This example adds a link that pre-populates a new e-mail with some information from the selected task. It uses the good old ’mailto:’ to open the default mail program for the client machine. If you don’t have a default mail client then, well, it won’t (harsh but fair).

This can be used as a quick way to create nagging e-mails for task owners, or to highlight tasks that may be of interest to others.


To add this option using Javascript, add the following to a CEWP:

<script type="text/javascript">
function getMailTo (ID)
var taskTitleLink = document.getElementById(ID).firstChild;
var mailTo = 'mailto:?subject=';
mailTo += encodeURIComponent(taskTitleLink.innerHTML);
mailTo += '&body=';
mailTo += encodeURIComponent('An intriguing task...\n\nTitle: ' + taskTitleLink.innerHTML + '\n');
mailTo += encodeURIComponent('Link: ' + taskTitleLink.getAttribute('href'));
return mailTo;

function Custom_AddListMenuItems(m, ctx)
CAMOpt(m,’E-mail’,’window.location=getMailTo(‘ + currentItemID+ ‘);’,’/_layouts/images/EMAILPST.PNG’);
return false;

To produce the same result using a CustomAction, using almost the same Javascript in the link; the following UrlAction should be used:

<UrlAction Url="javascript:window.location='mailto:?subject='+encodeURIComponent(document.getElementById({ItemId}).firstChild.innerHTML)+'&amp;body='+encodeURIComponent('An intriguing task...\n\nTitle: '+document.getElementById({ItemId}).firstChild.innerHTML+'\n')+encodeURIComponent('Link: '+document.getElementById({ItemId}).firstChild.getAttribute('href'));"/>

The differences between the two (other than the infrastructure used) are as follows:

  1. UrlActions are ugly not amenable to declaring Javascript functions in an readable way.
  2. URL in an UrlAction is  wrapped in a Javascript function (STSNavigate) when rendered in the OnMenuClick event attribute, so it needs the javascript: prefix to use such. The Javascript version is put in the same event attribute, but without the wrapping function no prefix is needed.
  3. currentItemId and {ItemId} both get the current List Item’s ID in their own contexts.

The code in both of the above examples take advantage of the fact the Title and link are within the div that shares this item’s ID. Using this method limits the amount of information we can get our hands on. We can get a little more using GetAttributeFromItemTable, but to get all the information we’d have to use some more contrived methods.

Shorten an item linkmenushorten

This option opens a new window to tinyurl’s site with the task’s abbreviated link posted through. If you’re using an earlier version of Flash than 10 (rather you than me) it’ll even put it in the clipboard for you.

As you may have previously seen, SharePoint links are often a nest of GUIDs. This allows a neat little link to be produced instead: great for optimising scary archaic communication methods such as paper documents or VoYP (Voice over Yoghurt Pot).

I’ve used tinyurl simply because you can send the link to be shortened in a querystring, and nothing else is needed. Much as I love fetching API tokens and/or posting plain text login details, I used the most straightforward method for brevity’s sake.

<script type="text/javascript">
function getShortenUrl(ID)
var shortenUrl = '';
shortenUrl += encodeURIComponent(document.getElementById(ID).firstChild.getAttribute('href'));
return shortenUrl;

function Custom_AddListMenuItems(m, ctx)
CAMOpt(m,’Shorten’,’‘ + currentItemID+ ‘));’,’/_layouts/images/LINK.GIF’);
return false;

There is very little difference between the two implementations, except as mentioned in the previous section.

<UrlAction Url="''+encodeURIComponent(document.getElementById({ItemId}).firstChild.getAttribute('href')));"/>

Copy to clipboard (IE only)menuclipboard

A slightly more obvious method of copying an item’s direct link to the clipboard than the right-click menu. Handy for quick intuitive copying, or for broken mice.

Unfortunately this functionality is restricted to Internet Explorer (which covers most SharePoint users). Alternative solutions and their problems are covered pretty comprehensively on this Stack Overflow question.

<script type="text/javascript">
function setClipboard(ID)

function Custom_AddListMenuItems(m, ctx)
if (window.clipboardData)
CAMOpt(m,’Copy to clipboard’,’setClipboard(‘ + currentItemID+ ‘);’,’/_layouts/images/CLP16.GIF’);

The above sample takes advantage of the Javascript method’s flexibility, and does not display the option if the window.clipboard object is not present (i.e. not IE). But due to the restrictive nature of the Custom Action, we don’t have that ability.

<UrlAction Url="javascript:if(window.clipboardData){window.clipboardData.setData('text',document.getElementById({ItemId}).firstChild.getAttribute('href'))}"/>


The two methods of adding to the List Item menu each have their own benefits and restrictions.

The CustomAction method allows site-wide distribution and can be bundled with other CustomAction modifications (such as changes to the command ribbon), but it lacks flexibility and has very little granularity in its release (an entire list type). It also requires Visual Studio, and access to install such features.

Using Javascript in a CEWP is very flexible and much more readable for anything more than a very straightforward action. It can be added by power users rather than developers, without even using SharePoint Designer. Unfortunately it has to be added on every target view individually. If the Javascript was added to the master page it would result in an even less targeted release than the CustomAction option.

Both of these methods have very little item data to hand, but both can be greatly extended by making use of AJAX calls to SharePoint Web Services, 3rd party services, or custom pages.

Editing The SharePoint List Item Menu (Part 2: Using Javascript)

Date:November 4th, 2010 Author: Tags: , ,
Category: SharePoint Development, SharePoint Ideas, SharePoint webparts, Training Comments:6 ;

MenuBeforeFollowing on from Part 1 of this series which covered Editing the SharePoint List Item Menu Using Elements, I thought it would valuable to reproduce the same results without using Visual Studio or SharePoint designer (Part 4 will be to do it without a monitor). This method will allow non-developers with view edit access to customise the List Item Menu.

In this example, a ‘View (new window)’ option will once MenuAfteragain be added to each item’s context menu to avoid the modal box, as illustrated to the right. Although as Christophe helpfully pointed out in response to Part 1, the modal boxes can be banished under the list’s Advanced settings. Fortunately there are many other uses for these techniques, as we will see in Part 3.

This example uses a Content Editor web part, which means the Javascript can be added on a view-by-view basis. This allows a more targeted release and can be added by any user with permissions to edit the view. However, it makes widespread distribution more difficult; putting the function in a master page can overcome this but will implement it for every item menu on every list.