Custom Field Type Properties in SharePoint : Buggy or Not?

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:

NO!

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.

.b

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.
Donate Bitcoins

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!

Tags: , , ,

Post Author

This post was written by who has written 426 posts on Furuknap's SharePoint Corner.

I do SharePoint. When I'm not doing SharePoint, I sleep, and then I dream about SharePoint. Oh, and I dabble a bit in cryptocurrencies (Bitcoin, Litecoin, etc)

6 Responses to “Custom Field Type Properties in SharePoint : Buggy or Not?”

  1. Calin May 7, 2009 at 9:28 pm #

    Hi,
    I guess you know a lot about sharepoint and since I’m new in this area (even with a huge background of ASP.NET and JavaScript) I want to ask you about my problem.
    What I want to do build a custom field type which will have a custom data type (ok let’s say it will be a string around 5 KBytes length) and based on that string I will show a dynamic image (build on server based on my data).
    The problem is because when the custom field type is shown in a list view the sharepoint does not even instantiate any of my 2 classes for the field. It will take the string value of property “Value” when a new item is added, will save that value as a string in database and then end of story.
    I searched for an explanation and here is what I found on Micsrosoft website:
    “However, the main advantage of using a rendering control is to provide data validation and processing, and those functions are not needed when the data (valid or not) is merely being displayed instead of created or edited. For that reason, none of the field types that ship with Windows SharePoint Services 3.0 use a rendering control rather than a *DisplayPattern* type of *RenderPattern* element to render the field in Display mode. Probably, all of the custom field types that you create will use a *DisplayPattern* for Display mode also.”

    Please tell me if I’m missing something otherwise I will have to make some ugly workarounds just because some guy from Micrsosoft thought that is not necessary to allow us to make a full custom rendering (with code behind logic not CAML )while displaying the custom field type in a list view.

  2. Bjørn Furuknap May 7, 2009 at 9:44 pm #

    Hi Calin!

    Sadly, you cannot do anything but CAML when rendering list views. The rednering controls render only columns in forms, not lists. What you get from the list is essentially an SQL dump of the values your field type stores, and the rendering control is never included at all.

    the good news is that you should be able to perform at least basic comparison against your text data, using CAML. You have caml elements such as Switch and FieldSwitch that you can use to at least get basic functionality.

    Your run-time options are very limited, though.

    Sorry to ruin your day.

    .b

  3. Calin May 10, 2009 at 2:02 pm #

    Hi,
    I have read about CAML and I saw some examples but it wouldn’t help me unless I can call C# code from CAML. Do you think if is possible somehow to call C# methods from CAML?
    Calin.

  4. Bjørn Furuknap May 10, 2009 at 2:09 pm #

    Not server side. Not unless you want to mess up the SharePoint database.

    You only option would be to deploy client-side script that calls server side script to output data. This, however, is very possible, and with your background in JavaScript, I'll assume you can get this to work.

    My question, however, is why? I don't understand the depth of your problem, so it is difficult to say that you ought to do this or that.

    If you send me an email to furuknap< []at]>gmail.com we can discuss in depth there, and I can post an article with the results so everyone can benefit.

    .b

  5. JohnC June 2, 2012 at 1:40 pm #

    Please provide a link or reference to the exact volume, issue, and page in Understanding SharePoint Journal issue 3 that contains your article on this topic. When I browse your link to their site I get only the home page with a nag popup and a paywall blocking my view of your article or reference at least. Thanks

    • Bjørn Furuknap
      Twitter: furuknap
      June 2, 2012 at 4:23 pm #

      JohnC,

      The issue is volume 1, issue 3, SPTags explained. The entire issue focuses on custom field type development.

      .b

Leave a Reply