All over the wide world web, SharePoint developers are screaming their lungs out about bugs in SharePoint custom field types, especially when working with custom properties in field types. The claims are that the SetCustomProperty and GetCustomProperty methods does not work at all, and never save anything. Not just that, but it is impossible to render any of the damn things.
So, are they right? Let me answer that, once and for all:
With that answer, the debate should be dead, once and for all. Thank you for your time, I’ll return shortly with another answer to another question.
Oh, you want to know more, do you? Well, if you had used some of that curiosity to investigate how custom field type properties works in SharePoint, perhaps the question would never arise?
Ok, I’ll try the short version here.
I explained in a previous post why custom field types have two constructors. I’ll elaborate a bit on the answer now.
When a user is creating a new column through the web interface, SharePoint uses two objects to handle the process. The first object is responsible for the interaction with the custom field type editor, which takes user input for any custom properties. the second object is the object responsible for creating and saving the new column to the list.
When the user hits OK to create the new column, SharePoint fires a method in the field editor class, called OnSaveChange. This method is passed an SPField object which on the surface seems to be the object representing the new field. However, it is not, and while it may seem like a strange notion, it does make sense from several perspectives.
First, consider what you would do if you need to validate the new field as part of the OnSaveChange method. If the column was already created, and its SPField object was sent to the method, how would you possibly be able to make any corrections or cancel the whole operation? Second, the method parameter is passed as a value type, not as a reference. Any changes you would make, such as setting custom properties, will simply disappear once the method completes.
The problem then is to find out how to send the custom properties from the field editor object to the object responsible for creating the column. You can use multiple methods for this, but in the upcoming Understanding SharePoint Journal issue 3 I will show you how to use Thread Local Storage to temporarily store the properties in memory so that the creator object can retrieve the settings later.
Other methods I have seen uses the list’s SPFolder properties as a storage mechanism, which sort of works, but only for list columns, and not for site columns. Of course, this may be a trade-off you are willing to make.
However, I chose the TLS method because that is what Microsoft does when they need to store custom properties. If you look at the BDC field type in reflector you will see how they do this. I figured, if Microsoft thinks it is OK, then who am I to argue.
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!