Jaap Vossers' SharePoint Blog

Just another WordPress.com site

Archive for March 2009

Released: SharePoint InstantListFilter

with 26 comments

The latest addition to my CodePlex portfolio is called SharePoint InstantListFilter.

It is an assembly free solution and you can even “install” it by editing the contents of a Content Editor Web Part! So what is it really? It is a javascript based solution that adds filter textboxes to every column of a SharePoint list view (SPGridView) with filter-as-you-type functionality. It uses jQuery to add the textboxes and perform the filtering.

Update: Live demo online

One cool freebie is that you can use it to filter on field types that normally aren’t filterable, like calculated fields and note (multiple lines of text) fields.


Instructions on how to install can be found on the CodePlex site.

Download SharePoint InstantListFilter @ CodePlex

Written by jvossers

March 30, 2009 at 8:40 pm

Released: SharePoint QuickLaunchExtender

with 11 comments

Most of the out of the box SharePoint sites use the QuickLaunch menu. The size of this menu gradually grows as the number of sub sites and lists grow. I have heard many people complain about how they cannot easily find a particular navigation item when it is so crowded.

I published a free solution on Codeplex called SharePoint QuickLaunchExtender. It enriches the QuickLaunch menu. It comes with a custom configuration page that allows you to specify the behaviour of the QuikcLaunch menu. It works on both WSS 3.0 and MOSS 2007. SharePoint QuickLaunchExtender comes with a Solution Package (WSP), so there are no manual installation steps to take.

This is the description of SharePoint QuickLaunchExtender on codeplex:

“Extends the SP QuickLaunch control to provide a richer experience. Configure it to transform the QuickLaunch into an Accordion, a set of collapsible/expandable panels (Adds scrollbar per panel if height limit is specified and exceeded), or a real-time filterable list. Uses jQuery”

Basically, in addition to the default behaviour of the QuickLaunch menu, there are three modes that SharePoint QuickLaunchExtender introduces.

  • Expand/collapse (optionally with configurable panel height limit)
  • Accordion
  • Filter

Expand/collapse mode allows you to click one of the headings – just right next the heading link) to toggle the expand/collapse state of the panel that contains its related child links. You can configure whether all panels should be expanded or collapse on page load. Also, you can specify a limit in pixels for the panel height. If the limit for any of the panels is exceeded because of the amount of links on that panel, a vertical scrollbar will automatically be added to that panel to cater for any overflow.

Accordion mode also allows you to click one of the headings, however, only one panel will be in expanded state at all times. You can configure the panel height in pixels.

Filter mode is a mode that has been added after the first release. It is now my personal favourite now! It adds a textbox to the top of the QuickLaunch menu and allows you to filter the links in the QuickLaunch menu in a filter-as-you-type manner. This is really useful when your QuickLaunch menu tends to get very big.

Demo screencast:

I apologise for the poor readibility in the video above. In the video I demonstrate the different modes of SharePoint QuickLaunchextender as I configure it using the custom configuration page

Download SharePoint QuickLaunchExtender @ CodePlex

Written by jvossers

March 29, 2009 at 11:47 pm

The WSP Boat

leave a comment »

At work I develop many Features and often wrap them in Solution Packages (WSP) so I can just throw it all over the fence of the company that is responsible for managing the servers and running code deployments. However, these guys did not actually understand what they were doing. They were blindly following the installation guide that describes the calls to stsadm for solution deployment. Sure, they managed to do what I wanted them to do, but I would prefer if they would understand what they were doing so they could do some troubleshooting if a Feature would fail to install for example. So I sat down with them and came up with an analogy of having soldiers (Features) that need to be deployed to battle fields (Web Applications) on a remote island (Farm). The soldiers need to be put inside a vehicle (WSP) that transports them to the barracks (Solution store) of the island. From there the soldiers can be deployed to the battle fields.

Obviously a WSP can contain more than just Features, but for the sake of simplicity I have not included deployment of 12 hive files, DLL’s, and CAS policies in the drawing.

I call it: The WSP Boat


Written by jvossers

March 26, 2009 at 2:28 am

Posted in Deployment, SharePoint

ASPX Workflow Task Edit Forms – The Easy Way

with 5 comments

When developing custom Visual Studio workflows for SharePoint you have the choice to use InfoPath form templates or ASPX forms for your task edit forms. Many people go down the InfoPath route because implementing ASPX forms is not as simple as you would hope. Doing it the ASPX way involves creating a dedicated Content Type for each type of task that your Workflow creates. You could actually end up managing dozens of Task Content Types, which is no good.

So why does the InfoPath approach not require all these additional Content Types? When using InfoPath forms, in your Feature that deployed the Workflow Template, you associated every single InfoPath form template (.xsn) with an integer value – the Task Type. In your workflow code, upon creation of a workflow task using the CreateTask activity, you can specify which InfoPath template should be used as the task edit form for this particular task. You do this by setting the integer property TaskType on the TaskProperties property on the CreateTask activity. This value should correspond with the value that you used to map to your desired InfoPath form template in your Feature.

Under the hood, this integer value will be used to set the value for the Task Type field (which is defined on the hidden Content Type “Workflow Task”) on the List Item representing the task.

If you are doing it the InfoPath way, your InfoPath Form will be dynamically loaded by /_layouts/WrkTaskIP.aspx as you navigate to your task, based on the Task Type field value on the task List Item.

Hold on a second… why not build our own equivalent of WrkTaskIP.aspx that does the same trick, but instead of loading an InfoPath template it will load a custom Control!

I am assuming you know how to create custom application pages that reside in the _layouts folder. Create a page at /_layouts/yourproject/TaskEditor.aspx with your code behind somewhere in one of your assemblies.

We need to update the Workflow Task content type to have its EditFormUrl and DisplayFormUrl properties point to our new page. This needs to be done through code just once, for example with a Console Application or an ASPX page with code behind.

using(SPSite site = new SPSite("http://yoursite"))
  SPContentType ct = site.RootWeb.ContentTypes[new SPContentTypeId("0x010801")];

  ct.EditFormUrl = "_layouts/yourproject/TaskEditor.aspx";
  ct.DisplayFormUrl = "_layouts/yourproject/TaskEditor.aspx";

Alternatively, if you don’t like changing the out of the box Content Types, you could create one single Content Type that inherits from Workflow Task and set the EditFormUrl and DisplayFormUrl properties on this Content Type.

Right. Now that we have our TaskEditor.aspx page and our Content Type set up we can start implementing TaskEditor.aspx and its code-behind.

Firstly, add an asp:PlaceHolder to the markup of TaskEditor.aspx and add a field member into the code-behind class with a name equal to the ID so we can reference it from our code.

We then need to override the CreateChildControls method of our page. We will dynamically instantiate our control (we don’t know what to load yet, but we will soon find out!) in here and add it to the asp:PlaceHolder’s Controls collection.

Let’s read the value of the Task Type field on the task List Item.

int taskType = (int)SPContext.Current.ListItem["Task Type"];

You should create a method that returns an object of type Control and accepts the integer taskType parameter. The implementation of this method is really up to you. I implemented it in such a way that it uses Page.LoadControl() to load an ascx UserControl that is expected to reside at /_controltemplates/myproject/taskeditors/[taskType].ascx

Convention over configuration, I love it.

Next, after calling your method that creates the Control, you need to add it to the asp:PlaceHolder’s controls collection.

We are almost there! All we need to do is create a Button (either on the Page, or in your Control) to attach the “Complete Task” code to, so the Workflow can resume its execution – assuming an OnTaskChanged activity is waiting for the task to be updated.

All that is required for the implementation of the event handler is this:


You could choose to set Status to Completed before updating it, or your could do this in your workflow by using a CompleteTask activity.

Obviously you would implement your custom controls based on your requirements, which may include things like validation + friendly validation messages, display of external data, capturing of additional data, and any other business logic. All things that are not too easy to achieve with InfoPath’s limited flexibility. And another cool thing is that the deployment process is so much easier now!

I hope this article was useful to you. I am sorry for not providing ready-to-run code, but it is merely the concept that I am trying to push to the outside world.


Written by jvossers

March 25, 2009 at 1:49 am

Posted in SharePoint, Workflow

Released: SharePoint InlineSiteSettings

with 4 comments

As a SharePoint developer, I have to navigate to the Site Settings page literally hundreds of times a day. I was getting fed up with the amount of steps required and the time involved to get to the Site Settings page.

For a WSS site:

  1. Move mouse to Site Actions menu
  2. Click Site Actions menu
  3. Move mouse to Site Settings menu item
  4. Click Site Settings menu item
  5. WAIT for page to load…

For a MOSS site:

  1. Move mouse to Site Actions menu
  2. Click Site Actions menu
  3. Move mouse to Site Settings menu item
  4. Move mouse to Modify All Site Settings menu item
  5. Click Modify All Site Settings menu item
  6. WAIT for page to load…

What’s that, 5 seconds maybe? Times 100?

If you are a good developer, your brains are likely to be moving faster than your hands. Having the system respond to your input without making you feel that you are being slowed down by it will greatly improve your development experience. To get into – and stay in – “the zone” you should not break that chain of quick commands. Shortcut, tab, tab, type, enter, mouse, click, f5, alt+tab, shortcut, woohaa – ninja mode!

This article is about a free solution that I developed that eliminates a painful sequence of mouse movements and clicks by replacing it with a single keyboard shortcut. Not only that! It will introduce direct navigation paths between pages that were not linked before. Navigate from Site Features to Site Content Types? From Content and Structure to Master Page Gallery? How?

  1. Keyboard shortcut
  2. Click link

SharePoint InlineSiteSettings will allow SharePoint users to press Ctrl+s to instantly access the Site Settings of the site belonging to the page you are currently on. It will actually be displayed inside the page you are currently viewing, at the top.

How does it work? SharePoint InlineSiteSettings performs an AJAX call to settings.aspx and extracts an html fragment from the response. This fragment is the table containing all the links that appear on the Site Settings page. By the time the user triggers the keyboard shortcut, the html fragment has already been loaded into the DOM of the current page, and only needs to be made visible – which is exactly what the javascript event handler for the keyboard shortcut does.

SharePoint InlineSiteSettings uses jQuery to perform the AJAX call, enable keyboard shortcut event handling (using the jQuery HotKeys plugin) and perform DOM manipulations.

SharePoint InlineSiteSettings has been implemented as a WebControl that will render mainly javascript, Certain properties can be set on the WebControl to customize its behavior. To allow deployment via a feature, I originally intended to implement a Feature that would use the AdditionalPageHead delegatecontrol. I soon found out that the BlueBand.master masterpage (which is the default master page for a publishing site) does not contain the AdditionalPageHead delegatecontrol, which meant that it would not work on a OOTB publishing site. For this reason, I came up with the alternative idea of implementing a custom Site Actions Menu Item that would not really render a menu item, but would only drop the javascript in the head of the page.

In terms of deployment, you can choose whether you prefer to add the WebControl to your master page, or activate a Feature that will register a custom Site Actions menu item. In the latter scenario you have the option of specifying if you want preloading turned on or off. This is done by activating one of the two available site collection scoped Features: InlineSiteSettings vs InlineSiteSettingsNoPreload. Make sure you only have one of these Features activated at a time. No preload basically means that the AJAX call to settings.aspx will be performed as you trigger the keyboard shortcut, which means you will save bandwidth at the price of response time.

The assembly that contains the InlineSiteSettings WebControl also contains the jQuery and HotKeys javascript libraries as embedded resources. These will be references automatically by the InlineSiteSettings WebControl, unless you specify that you do not want this to happen. This can be cone by setting the appropriate properties on the InlineSiteSettings WebControl. This is only possible if you add the InlineSiteSettings WebControl to your master page.

SharePoint InlineSiteSettings is published at CodePlex. It comes with a WSP that will deploy the Features and the required DLL. This DLL will be deployed to your bin folder and comes with a custom CAS policy.

Download SharePoint InlineSiteSettings @ CodePlex

Written by jvossers

March 19, 2009 at 12:14 am

Another blog has spawned

leave a comment »

Welcome to my blog. Please do come back more often if you are interested in posts on SharePoint development, jQuery and general .NET development.

In my first few posts I will walk through the CodePlex projects that I have recently published. All three of them are enhancements to the standard SharePoint UI and are based on jQuery.

Come back soon!

Written by jvossers

March 16, 2009 at 11:39 pm

Posted in Uncategorized