How to build a WSS custom list item ID field

• Download source code - 9.25 KB

Introduction

This article introduces a way to create a key column in a SharePoint list.

Background

In WSS 3.0, every list item has an ID field which is read only. However, a SharePoint developer may find it is difficult to make advantage of the ID field in customized list items. They need a unique key field which is read only and whose value can synchronize with the ID field. Furthermore, it's better to make its value customizable like Project ID 1001, 1002 or Sale Order 70001, 70002...

Using the Code

The logic to implement this unique key field includes two things: a custom field type which is an integer and is read only, and an event handler feature which forces the new item value to be added by one automatically.

Let's see the code in the custom field type first:

public class CodeProjectNumberField : NumberField
{
    protected override void Render(System.Web.UI.HtmlTextWriter output)
    {
        try
        {
            if (Controls.Count > 0)
            {
                ((TemplateBasedControl)Controls[0]).TemplateName = 
                    "~/_controltemplates/CustomTemplates.ascx";
                base.Render(output);
                output.Write("Read Only Field");
            }
            else
                base.Render(output);
        }
        catch (Exception ex)
        {
            PwCPMOExceptionLogging.Error(ex);
        }
    }
}

In the project custom field type, we customized the number field control's template to customTemplate.ascx. In this Custom Template file, we can easily set the number field control as read only. Please check the Custom Template file and compare it with HIV12\TEMPLATE\CONTROLTEMPLATES\DefaultTemplates.ascx.

Now, let me introduce the event handler feature. We will set the key field value and format it at the time of ItemAdded:

public class ReceiverHandler : SPItemEventReceiver
{
    public override void ItemAdded(SPItemEventProperties properties)
    {
        string CodeProjectCustomFieldName = 
          ConfigurationSettings.AppSettings["ProjectChangeTrackingNumberFieldName"];
        string CodeProjectCustomFieldSeed = 
          ConfigurationSettings.AppSettings["ProjectChangeTrackingNumberFieldSeed"];
        if (!properties.ListItem.Fields.ContainsField(CodeProjectCustomFieldName))
            return;

        int intCodeProjectCustomFieldSeed = 1000;
        Int32.TryParse(CodeProjectCustomFieldSeed, out intCodeProjectCustomFieldSeed);

        properties.ListItem[CodeProjectCustomFieldName] = 
          (properties.ListItem.ID + intCodeProjectCustomFieldSeed).ToString();
        properties.ListItem.SystemUpdate();
    }
}

We set the FieldName and ListName in the web.config file to force this event handler to only affect the field we defined. We also have to define the field seed to customize the value format. Then, we calculate the new field value based on the item ID values...

One important thing I have to say is that after all the event handler and custom field types are created and deployed, we have to customize FLDTYPES.XML under the folder HIV12\Template\XML to make the new field type appear when creating a new list column. (I suggest creating another FLDTYPES.XML like fldtypes_codeproject.xml instead of using the existing one. The reason is it may be overwritten when WSS is updated.)

Points of Interest

While figuring out this solution, I felt Microsoft SharePoint team is always trying to make their products better to meet end user requirements, and I believe we will be able to see Microsoft's implementation on this issue in the next version.

History

I will keep updating as I dig into the SharePoint world. In fact, there are lots of issues like this. I think Microsoft may make WSS 3.0 much better if they get more time before publishing the next version.

This article, along with any associated source code and files, is licensed under The Common Development and Distribution License (CDDL)