Steve's SharePoint blog

I had a requirement to use the new sub folders feature of WSS 3.0 for lists and had a dig around the object model on a way to implement it.

The SPList object has a handy way of referencing the subfolders through _spList.RootFolder.SubFolders and there are methods on the returned object that allow you to manipulate the folders.

Such a method is the Add method which takes a folderName parameter – great!

However, if you create a folder this way and look at the list through the browser, you will not find the folder.  It is there, but it is completely hidden!

Perversely, Redmond decided that this was not the way to create folders in WSS 3.0, and they are actually created using the following code:

SPListItem newFolder = _spList.Items.Add( "", SPFileSystemObjectType.Folder, folderName);

newFolder.Update();

Basically you are creating a new list item with a 'Folder' type.

Thanks to Paul, our Microsoft consultant, for locating the correct way of doing this!

I quite often use hidden web part properties for sensitive information and properties that I just don't want the user to update.  With WSS 2.0 and the Microsoft.SharePoint.WebPartPages.WebPart namespace, this was easily achieved by setting:

this.SaveProperties = true;

On moving to MOSS and WSS 3.0 I decided to use the System.Web.UI.WebControls.WebParts.WebPart namespace (as recommended) and of course the SaveProperties property does not exist.  I could of course continue using the original namespace, but that would mean that the web part could only be hosted on a SharePoint site, and it was my intention to broaden the scope a little.

After a fair amount of Google searching I stumbled across the solution.  The method I was looking for was:

this.SetPersonalisationDirty();

So problem solved!

I am currently working on a large SharePoint project looking to migrate to MOSS 2007.  I have been involved in the investigations into the migration of our custom 2003 web parts over to MOSS.

One of my current challenges is to replace the top navigation bar with custom tabs, as our customer does not require the 'standard' set of tabs to be displayed.  Also the tabs are dynamic depending on what level of user is logged in and what responsibilities they have to the organisation.

So far I have found 2 strategies:

1. Add a custom web part to the page that will generate the custom tabs when the page is loaded.  This also requires the 'My Home', etc tabs to be removed via editing the master pages.  This is quite slow and increases the load time of the page.
2. Add a custom navigation provider to the master page.  This is quite involved but does have the advantage of fast load times for the page if implemented properly.

Will post more details later as I am in the middle of developing something else (non-sharepoint)