Setting the Title field for Content Types

This is one I’ve been meaning to blog about for a while. I was using a Content Type where I was trying to set the display name of ‘Title’ field. I was happy to have a Title column, but I wanted it to have a different name.

I tried doing this declaratively:

<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" DisplayName="Request" Required="FALSE" />

However, I found this didn’t work in SP2010 – the field still appeared as ‘Title’. This was frustrating.

Instead, I had to set the Title’s display name in code:

foreach (SPFieldLink fldLnk in contentType.FieldLinks)
{
if (fldLnk.Id == SPBuiltInFieldId.Title)
{
fldLnk.DisplayName = "Request";
}
}
contentType.Update(false);

This was a bit strange – other fields can have a DisplayName set in CAML quite happily. This seems to just be a feature of the Title column.

EDIT: I also had to use a similar approach on setting the Title column for a content type used on a list – but using:

private void SetTitleField(SPWeb web, string listname, string contentTypeName, string newTitleName)
{
SPList list = web.Lists[listname];
SPContentType ct = list.ContentTypes[contentTypeName];

foreach (SPFieldLink fldLnk in ct.FieldLinks)
{
//Necessary to set title field - when using content types, this seems to set it to "Title" irrespective of what is set in the Content type or list's XML.
if (fldLnk.Id == SPBuiltInFieldId.Title)
{
	fldLnk.DisplayName = newTitleName;
	ct.Update(false);
	break;
}
}
foreach (SPField fld in list.Fields)
{
if (fld.Id == SPBuiltInFieldId.Title)
{
	fld.Title = newTitleName;
	fld.Update();
	break;
}
}
}
Setting the Title field for Content Types

Delete Event Receiver from a Content Type with Code

SharePoint allows you to attach event receivers to content types. That’s pretty handy. Unfortunately, deleting event receivers from those content types is much more hard. Perhaps this is why the Document ID feature fails to remove the content types that it adds. However, here is one possible approach.

SPContentType ctype = site.RootWeb.ContentTypes[SPBuiltInContentTypeId.Document];
if (ctype != null)
{
 if (ctype.EventReceivers != null)
 {
   bool bContinueDelete = true;
   while (bContinueDelete)
   {
     if (ctype.EventReceivers.Count < 1)
     {
       bContinueDelete = false;
     }
     else
     {
     bool bFoundOne = false;
     foreach (SPEventReceiverDefinition d in ctype.EventReceivers)
     {
         //Could match on the Type of the event receiver, but for this example, let's use name
         if (d.Name.Contains("Document ID"))
         {
           d.Delete();
           ctype.Update(true, false);
           bFoundOne = true;
           break;
         }
     }
     if (!bFoundOne)
     {
       bContinueDelete = false;
     }
   }
 }
}

More on why this is important in a later post.

Delete Event Receiver from a Content Type with Code

Programmatically making a Field Required in SharePoint 2007

One of my colleagues asked an interesting question – programmatically, he’d just added a Site Column to a list, and now he wanted to make that column required on that list. The SPField class had a Required property, and on MSDN this is described as

Gets or sets a Boolean value that determines whether users must enter a value for the field on New and Edit forms.

However, this wasn’t what seemed to happen – although he’d set this to true and update the field, it didn’t make the field required.

He came and asked me why – and I didn’t really know. We knew that the radio button on the column settings did what we wanted …

… so we cracked open reflector to take a look. And this is what we found:

Yup, that’s right – if the field is on a list, the list uses content types, and “Advanced Management of Content Types” isn’t set, then the code gets the first (i.e. Default) content type, and sets the SPFieldLink that relates to that field to be required. Finally, it saves changes to the content type.

So, on a list that doesn’t use content types, to make a field required, you have to update the content type. Interesting…

Programmatically making a Field Required in SharePoint 2007

Registering EventHandlers against ContentTypes

In SharePoint, Event Handlers (or Event Receivers – whichever terminology, a child of SPItemEventReceiver) can be registered against lists/libraries. You can do this through an SPWeb (site) scoped feature, declaratively or programmatically with an SPEventReceiverDefinition.

Unfortunately, you can’t declaratively register event receivers at the SPSite (Site collection) level – which would be fantastic – just turn on the feature and across all your site collection lists/libraries of a give type would get additional event receivers. Personally, I think this may be a bug; I don’t see why this shouldn’t work at the SPSite level.

Anyway, there is still another option – we could register our event against a particular Content Type. This is a less often used approach, which raises two questions – how do you do it, and what happens to child Content Types? Continue reading “Registering EventHandlers against ContentTypes”

Registering EventHandlers against ContentTypes

Weird ContentType of Blog Posts

Okay, this is weird.

I’m trying to do something with various types of item, including Blog Posts, in SharePoint. Naturally, I’m getting the SPListItem for them, and then the SPListItem.ContentType, so I can check what kind of item is it. The weird thing is, if I try to get a Blog Post, the SPListItem.ContentType is NULL. Continue reading “Weird ContentType of Blog Posts”

Weird ContentType of Blog Posts

Programmatically Create Content Types

This is an example of programmatically creating a content type (based on the Document content type) and adding it to a list. I’ve not added any extra columns or anything – but we could have.

string name = ...
SPList list = ...
SPContentType baseContentType = web.ContentTypes[SPBuiltInContentTypeId.Document];
SPContentType type = new SPContentType(baseContentType,web.ContentTypes,name);
list.ContentTypes.Add(type);
list.Update();

Programmatically Create Content Types