Author / Simon Doy

Unknown's avatar

Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.
by Simon Doy

Error when creating custom list from New.aspx


>

Introduction

Anyone who’s been developing SharePoint will I am sure have had problems building custom list schemas. However, this one I hadn’t seen before.

The Problem

A custom site definition had been built which activated a feature which created an instance of a custom list for holding event list items.

When the site was created the events list was created perfectly, no problems.

However, when the list is created through the GUI, by clicking on Site Actions->View All Site Content and clicking Create and choosing the custom list type.

This brings up the new.aspx form, once the title and description is filled out and the create button clicked then the following exception was thrown :-

Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION)) at Microsoft.SharePoint.Library.SPRequestInternalClass.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)
at Microsoft.SharePoint.Library.SPRequest.CreateListFromFormPost(String bstrUrl, String& pbstrGuid, String& pbstrNextUrl)

Solution

So the problem is something to do with the list schema.xml file. This schema.xml file is found in the feature directory. I use the following directory structure:-

12HIVE\Templates\Features\ListFeatureName\ListName\schema.xml

Looking at the error, the stack trace mentions the function, CreateListFromFormPost. I thought the issue was due to a custom NewForm page that we were using.

I could not find anything that would fix the issue, even replacing all the custom xml relating to the NewForm element.

However, the schema.xml was missing an attribute, this was the Url=”” attribute part of the <List> element.

This issue was found by comparing the schema.xml file with an out of the box schema.xml. As soon as the Url attribute was provided (even if the attribute was blank) then the list was created properly.

To recap the section of the schema that needed to updated was:-

<List xmlns:ows=”Microsoft SharePoint” Title=”Events” DisableAttachments=”TRUE” FolderCreation=”FALSE” Url=”Lists/Events” EnableContentTypes=”TRUE” BaseType=”0″>

The way that a list is created through a List Feature Instance must be called by some separate code function probably something like CreateListFromListInstanceFeature() instead of CreateListFromFormPost() and hence the list is created ok by the List Feature.

There are a few conversations about this on MSDN but when I first read them I didn’t realise the solution that they were pointing to.

These posts are:-
http://social.msdn.microsoft.com/Forums/en/sharepointcustomization/thread/458e5716-4fa4-425c-9fda-88ce4ccc6203

and

http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/86dd7485-48cc-4836-ad09-40192bd54841

Anyway hope that helps.

Simon

by Simon Doy

Experiences applying SharePoint Themes to a SharePoint Farm


So I have already written this blog post once, but Windows Update decided to reboot as I was finishing the blog post. Unfortunately I hit Ctrl + V as it asked if I wanted to save the post – then it rebooted.

Windows Live Writer has an auto save post function, I have now enabled this to save further frustrations. Shame it’s not on by default!

Anyway so what did I write..?

I have been recently updating some themes that have already been deployed to a SharePoint farm. I thought the process would be pretty straight-forward as the files were already packaged up as a WSP. I thought the process would be something like this:-

  • update theme.css within the theme folder
  • package up the changes into a WSP file
  • update the solution with stsadm –o updatesolution

Unfortunately this wasn’t the case.

So what happened? Well I updated the solution and loaded up the SharePoint site and nothing had changed. “Ah ha” I thought it’s probably because IE is caching the CSS file. So pressed CTRL+F5 to expire the cache the page loaded again with no change.

Using the IE developer toolbar I selected the element and used trace style to find out why the CSS class hadn’t changed. The toolbar opened up a strangely named CSS file called ITSP1001-65001.css. Looking at the CSS styles I could see that yep, the style hadn’t changed.

So what the heck was this file? I certainly hadn’t created it and its not in my THEME folder inside c:\program files\common files\microsoft\web server extensions\12\template\themes\THEME.

After some investigation and reading a couple of blog posts such as this one from Shane Perran’s blog site. (http://www.graphicalwonder.com/?p=419)

I discovered that the file is automatically created when a theme is applied.

So what happens? Well SharePoint merges the following css files:-

  • core.css
  • [alternative css file for your site definition]
  • theme.css

This creates a file using the first 4 letters of the THEME name with 1001-65001.css  appended to the end. This file along with the rest of the files from the Theme folder is uploaded into a folder _theme/THEMENAME found at the root of the site. You can see this folder in SharePoint Designer.

So because this file is only created when you apply a theme that is why it was not updated when the solution updated. So I applied the theme again and still no luck!

It turns out that you need to apply another theme first such as CLASSIC and then reapply your custom theme.

Tada the theme is now updated!

Unfortunately the process of reapplying the theme is tedious but fortunately Gary LaPointe’s stsadm extensions came to the rescue in the form of stsadm –o gl-applytheme (http://stsadm.blogspot.com/2008/01/apply-theme.html).

The following stsadm commands were used:-

  • stsadm –o gl-applytheme –theme CLASSIC –url [http://sharepoint]
  • stsadm –o gl-applytheme – theme THEMENAME –url [http://sharepoint]

Once all the changes had been made then all the sites needed to be updated, not a fun task! Once again the stsadm –o gl-applytheme came to the rescue in the form of a recursive option.

Using the stsadm command with the recursive option all the SharePoint site collection were updated in no time.

I hope that this post helped, if you have any questions or there is something that you need more info on then just leave a comment.

Thanks for reading

Simon