Question: Why are there always two constructors in a SharePoint custom field type class?

I’ve worked a bit recently on custom field types in SharePoint for an upcoming Understanding SharePoint Journal issue. Actually, I’ve worked with custom field types for a long time, one of my first WSS3 project involved creating a cascading custom field type. Looking back I think it would have been easier, and less painfull, to eat my own eyes.

One thing that puzzled me in the beginning, which actually puzzled me still, is why you must always have two different constructors in your field type class. Just the other day a friend of mine asked about this when he looked at one of the field type classes I made for him.

public MyFieldType(SPFieldCollection fields, string fieldName)
: base(fields, fieldName)

public MyFieldType(SPFieldCollection fields,
string typeName, string displayName)
: base(fields, typeName, displayName)

The short answer is: Don’t ask.

The reason why you shouldn’t ask is that the answer cannot be made short in any situation. The answer is actually closely tied to the problems you face if you try to store custom field type properties.

As you may or may not know, storing custom properties for columns based on your field type is actually impossible, or at least incredibly difficult. The reason is that there are two different objects created from the same class that are responsible for creating a new column based on your field type. These two objects are not only completely separate objects but perform completely different tasks in the column creation operation. One objects handles the custom property input while the other object is responsible for creating the column in the list.

You’ll have to wait for the journal issue that deals with custom field types for the deep details on how custom field types work in SharePoint, but at least you should know that the two constructors are there to create two different objects.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

6 thoughts on “Question: Why are there always two constructors in a SharePoint custom field type class?”

  1. Actually, there are issues with Anton’s solution. His solution, by the way, is what is used in the WSPBuilder item template.

    I’ll detail everything in the journal, explain why this is an issue as well as how to work around the issue using different methods.


  2. Bj0rn, I read your journal on custom field types and tried to implement your method but found a small problem. If you add the field type twice to the list the properties of the first added field type is assigned to both. For example I created a custom field type for regular expressions. If I add the field as Phone and again as Email, the properties I put in for Phone will be used for both.

    This same thing happens with your SPTags example. If I add yours as Tags 1 and Tags 2 to the same list, the Tags 1 properties will be used for both fields.

    Do you think there is a way around this? I’m going to work on it but if you have any ideas I would love to hear them.

  3. Hmm I also just tested this by using the custom field type in two different lists and when you change the properties in one list it changes the properties in the other list for the corresponding column.

  4. Thanks for provided information at a hand. I'm reading a lots of SP blogs, but what is seen here is that experience and proficiency tells more than words. Thank you once again.

Leave a Reply

Your email address will not be published.