There are still times, however, when you’d want to use the functionality [...]]]> After the release of Sharepoint 2010, the request for Cascading Drop Down, filtered drop down, dependent drop down or what you call them is not so common anymore. The reason for this is of course the Managed Metadata Service, which is included in Sharepoint Server 2010.

There are still times, however, when you’d want to use the functionality below to filter your drop downs. If you for instance are running Sharepoint Foundation, not Server, you won’t have the Managed Metadata Service available at all. Or perhaps you are running server, but you want to use list data and not terms from the term store.

Read more about Cascading Drop Down in my previous post for Sharepoint 2007.

The solution
The solution below is tested with Sharepoint 2010, and is basically the same procedure as the one for 2007. The list is still standard Sharepoint, which gives great flexibility and stability. This way, the filtering is done in the forms for creating and editing elements. Because of this, you don’t even have access to the server to implement this.

1. Add the Jacascript
Download the Jquery file jquery-1.6.2.min.js by Jquery.com. Download jquery.SPServices-0.6.2.zip from the Jquery Library for Sharepoint Codeplex site (newer version is probably also OK). Upload jquery-1.6.2.min.js and jquery.SPServices-0.6.2.min.js (from the zip file) to a document library that everyone accessing your site has access to (a library on the top level site can be wise).

2. Create your relationship lists
Make two lists, one for the parent (Country) and one for the child (City):

Countries list:

Cities list:

The Country column can be a look up from the Countries list, but you can just as well use a standard single line of  text column, which I have done here. This can theoretically give better performance, but you must of course be precise when filling out the County column so that the values here matches the ones in the Countries list.

3. Create the list that is actually using the Drop Down

Vacation Plans list:

This is the list where I want my Cascading Drop Downs. Country and City are lookup columns against Countries and Cities lists. The lookups goes against the title field in the respective columns.

4. Make the magic happen
In Sharepoint Designer, create your own NewForm.aspx (or EditForm.aspx, you’ll need both if you want it to work when editing items). Editing forms is a lot easier now with Designer 2010.

Just below
<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">

insert this code:

<script language="javascript" type="text/javascript" src="/address to document library/jquery-1.6.2.min.js"></script>
<script language="javascript" type="text/javascript" src="/address to document library/jquery.SPServices-0.0.6.min.js"></script>
<script language="javascript" type="text/javascript">
 $(document).ready(function() {
  $().SPServices.SPCascadeDropdowns({
   relationshipList: "Cities",
   relationshipListParentColumn: "Country",
   relationshipListChildColumn: "Title",
   parentColumn: "Country",
   childColumn: "City",
   debug: true
  });

 });
</script>

Save and create a new item using your new form:

Voila!

5.Explained:
relationshipList: “Cities” : this is the name of the relationship list = the list containing parent and child
relationshipListParentColumn: “Country” : Column name from the Cities list
relationshipListChildColumn: “Title” : Column name from the Cities list
parentColumn: “Country”: Column name from the list where the drop down is = Vacation Plans
childColumn: “City”: Column name from the list where the drop down is = Vacation Plans

You have lost of other options explained at the project site on Codeplex like sorting, multiple levels and so on.

Thanks to Marc D. Anderson for making this available.

I tested this on Sharepoint Server Enterprise 2010 with Service Pack 1 installed. It should work just as fine on Sharepoint Foundation. My installation is English Sharepoint with Norwegian Language Pack, but pure English should be jsut as fine.

Sharepoint 2010 (Server or Foundation) is installed, and you also have installed one or more language packs.

You update the SPWeb web.Title programmatically (web.Title = “New Title”, web.Update();) in C#, but the title is not updated in your browser. This will happen if your Sharepoint installation for example is English (1033), and your site is [...]]]> Scenario:

Sharepoint 2010 (Server or Foundation) is installed, and you also have installed one or more language packs.

You update the SPWeb web.Title programmatically (web.Title = “New Title”, web.Update();) in C#, but the title is not updated in your browser. This will happen if your Sharepoint installation for example is English (1033), and your site is created in Norwegian (1044). It doesn’t matter if the installation language isn’t activated as a possible display language for your site, your updated title will only show when you choose the installation language as Display Language.

If you debug, you will se that the property web.Title is updated, but this is not what is shown in the browser. If you search further through the site’s properties when debugging, you will find a property called m_strTitle that holds your original title and obviously needs to beed updated. But, you cannot update this property directly.

So, how do you update the title in all Display Languages of the site?

SPUserResource resource = web.TitleResource;
foreach (CultureInfo culture in web.SupportedUICultures)
{
Thread.CurrentThread.CurrentUICulture = culture;
resource.Value = "New Site Title";
}

This also applies to for example web.Description, but not web.Name (which also is basis for the Site’s URL).

Remember to call web.Update, and ofcourse to do a web.Dispose if you are not using Using:)

you create a sandboxed solution in in Visual Studio 2010 for Sharepoint 2010, and you use a feature receiver to handle upgrades. You add a CustomUpgradeAction to your feature.xml file to fire some code when feature is upgraded.

You forget that you cannot simply write to the event log or the Sharepoint (ULS) logs [...]]]> So,

you create a sandboxed solution in in Visual Studio 2010 for Sharepoint 2010, and you use a feature receiver to handle upgrades. You add a CustomUpgradeAction to your feature.xml file to fire some code when feature is upgraded.

You forget that you cannot simply write to the event log or the Sharepoint (ULS) logs in a sandboxed solution, and add some code like this:

SPSecurity.RunWithElevatedPrivileges(delegate()

{

        System.Diagnostics.EventLog.WriteEntry("My Company, solution x", ex.Message);

});

in the FeatureUpgrade method to write something to the event log, maybe to check what went wrong if you have some errors in your code.

You will see that the FeatureUpgrade method is not firing when upgrading. You won’t get any errors either, and attaching to the SPUCWorkerProcess.exe for debugging won’t help either – nothing happens.

To make things work, you have to remove the statement writing to the log, this prevents the event receiver to function properly.

P.S. If you add a statement like the one above to the FeatureActivated method, you will at least get an error message so you know what’s happening.

You can download the final version here and try it out for yourself: http://www.microsoft.com/downloads/details.aspx?FamilyID=49c79a8a-4612-4e7d-a0b4-3bb429b46595&displaylang=en

& ~ # %  * ? / + | ” . _ { } \ : < >

Underscore is to be avoided as the first character in the name, and multiple consecutive periods should be avoided. In [...]]]> When naming your files, folders (but you usually don’t want folders anyway) and sites, avoid these characters:

& ~ # %  * ? / + | ” . _ { } \ : < >

Underscore is to be avoided as the first character in the name, and multiple consecutive periods should be avoided. In columns and document library names I also prefer to avoid Norwegian letters like æ,ø and å, and spaces. I rather rename the column or document library afterwards, getting a nice looking name combined with a coder-friendly URL (I get no sleep when I see URL’s like bad%20url.)

The dashboard can be always on, off or on demand. The latest option is the most useful for most scenarios, and gives you [...]]]> Sharepoint 2010 has a very useful function called the Developer Dashboard. When you enable this, you see what kind of resources the different requests on the page uses, the different queries etc.

The dashboard can be always on, off or on demand. The latest option is the most useful for most scenarios, and gives you a button on the page that you can click on each page individually to view the dashboard. This way, you can even use it in a production environment (of course not for testing new functions, you have a development, testing and staging platforms for that, right?). To enable the dashboard all you have to do is run this simple stsadm command. You can also use Powershell if you prefer that.

stsadm -o setproperty -pn developer-dashboard -pv ondemand