Home > MOSS 2007 > SharePoint issues and work arounds!

SharePoint issues and work arounds!


Cannot set Internal Name of an SPField:

The InternalName property is read only. According to the documentation the StaticName property of an SPField should:

“Get or set the internal name of the field. “

It doesnt! We had a requirement where we needed to set the InternalName of an SPField. We tried everything! various methods, reflection you name it but to no avail!

Trouble with getting SPField object after programmatically adding it:

There are a few ways you can add an SPField to a List.:

  1. SPField.Add() has three overloads
  2. SPField.CreateNewField()
  3. AddFieldAsXml() has 2 overloads

Using SPField.Add you can add an SPField by providing the DisplayName, Type and a bool specifying whether the field is required or optional. But how do you get a reference to the SPField you just added when you use this method?

You could use:

  1. SPField[int index] but you dont know the index
  2. SPField[Guid id] but you dont know the Guid
  3. SPField[string DisplayName] you do know the DisplayName but what if there is another field with the same DisplayName since there is no restriction on having more than 1 fields with the same DisplayName?
  4. SPField.GetField(string displayName) same problem as above
  5. SPField.GetFieldByInternalName(string internalName) but we dont know the internal name (linked with the issue mentioned above. This is why we needed to be able to set the InternalName).

If there was a GetFieldByStaticName it could have solved our problem. One of the overloads of the SPField.Add() method takes an SPField. We thought we would instantiate and setup our SPField object, pass it to that method to add to the List and we will then have a proper reference of our newly added SPField object right? No wrong! The SPField object is just a means to send in the data required to set up the new SPField.

It would be useful to have a method that will add an SPField and return an SPField object representing the SPField you just added. However in the absence of this there is a way around this whole issue. The way around it is to use the AddFieldAsXml() method. It takes a string argument representing the CAML for the SPField you are trying to add. In that you can specify the Guid you want for your new field. Later you can retrieve your field by using SPField[Guid id].

You can find the solution here.

Basic issue all over the place in the SharePoint Object Model:

You are adding an SPList programmatically. You want to find out whether an SPList with that name already exists. What do you do? You could try:

  1. SPList[string listName]
  2. SPWeb.GetList(string listName)
  3. SPWeb.GetListFromUrl(string pageUrl)

If the list exists it will get you the SPList object representing that list. If it doesnt it throws an exception! So if you dont have a try catch block when checking if a List with a particular name already exists your application will crash!

I think there is a need for a method which will return a particular value based on whether an SPList with that name exists (could return a bool, or the SPList object if it exists or null if it doesnt).

When adding an SPList you need to check whether an SPList with the same name exists or not because if it does then the SPList.Add() method will throw an exception. In other words it all works perfectly if you add a List and by chance the name is unique. If it is not unique then an error will be thrown and must be caught to prevent your application from crashing.  Surely, you should be able to check whether a list exists without having to catch an error!

This issue manifests itself in a lot of places in the object model. You have the same problem when trying to add an SPField, SPView e.t.c.

While programmatically adding a ListViewWebPart you cannot set the ToolbarType property:

There is a property called ToolbarType on a ListViewWebPart which is read only. There is a way around this issue which involves using reflection.

The work around for this is discussed here.

No clear way of adding Tabs to a Meeting Workspace Site:

When you create a site from the OTB Meeting workspace site definitions you are able to add pages to the site. The pages are stored in a hidden list called Workspace pages. When you add a page it adds a tab for that page at the top. However adding a WebPart page to this list programmatically doesnt solve the problem as it will not add the tab. There is a very painful way around this and it involves Reflection!

The solution is here.

Adding a WebPartPage to an SPList sub folder:

There is a way of adding it to the root folder but there doesnt seem to be a direct way of adding it to a sub folder. Again there is a way around this. You add the WebPartPage to the root folder of the SPList and then move it to the sub folder you actually wanted to add it to.

You can find a solution for this here.

Cannot get WebParts from a MySite (SPS 2003):

Not sure if its the same on MOSS 2007 but when we tried to get WebParts from the default page on a Personal Site (unless its your Personal Site) you wont be able to get an instance of the WebParts that exist on the page. Raised this issue with Microsoft who said this was for security reasons. However no such restrictions when trying to get data from the lists on the Personal Site 🙂 Run with elevated priviledges makes no difference either. The only way around this is to impersonate the user whose Personal Site it is or just give up!

Advertisements
  1. February 13, 2010 at 6:33 pm

    There is a similar bug with site columns. In a feature receiver deactivating a site column, you can get all the usages of the content type to delete them all (to avoid leaving customized orphans that won’t get updated at reactivation — due to the bug in content type & site column deployment lacking any handling equivalent of the GUI Update flag).

    But there is no analogous method to get all usages of a site column.Therefor you must iterate through all lists checking to see if the site column is in use — and the only way to do that, is to attempt to access it in every list, causing exceptions all over the place — the only way to find out if it is used, is to attempt to index it by ID. If an exception is thrown (and trapped, of course), then it wasn’t in use by that list.

    That is a very sad method of finding all uses, deliberately causing exceptions for most lists of every subweb.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: