Second Life of a Hungarian SharePoint Geek

September 16, 2009

Workaround for the custom site column property bug

Filed under: Bugs, Custom fields, SharePoint — Tags: , , — Peter Holpar @ 03:35

As so many other SharePoint user, administrator or developer (see MSDN forum threads here: Custom Field Type error, but only for site columns, Custom Field Selection in Site Column fails), we also found that after the SP2 our custom fields that have the PropertySchema tag and custom properties defined in their XML definition file, face to the error below:

Object reference not set to an instance of an object. at 
Microsoft.SharePoint.WebControls.FieldProperty.Render(HtmlTextWriter output)

As we already had issues with this kind of custom field properties (described well here: SharePoint Custom Field Weirdness), we assumed that the source of the problems is the PropertyIterator that is responsible for the custom field property rendering

The code behind for the FldNewEx.aspx page is in the FieldNewPage class, and the code behind for the FldEditEx.aspx page is the FieldEditPage class, both of these are derived from the FieldCustomizationPage class. Each of these classes are in the Microsoft.SharePoint.ApplicationPages namespace and in the Microsoft.SharePoint.ApplicationPages assembly. The CreateChildControls() method of the FieldCustomizationPage class creates a ListFieldIterator instance based on the PropertyIterator template, and loads that into the Customization control of PlaceHolder type.

The PropertyIterator template is defined in the DefaultTemplates.ascx file in the TEMPLATE\CONTROLTEMPLATES folder. After a short experimenting and a few IISRESET it was clear to us, that the error can be corrected, when we remove the line stroked through below (see the remark at the bottom of the post!), of course, only after creating a backup copy of the DefaultTemplates.ascx into another (it is important not into the CONTROLTEMPLATES) folder, for example C:\Temp is a perfect choice:

<SharePoint:RenderingTemplate ID="PropertyIterator" 
runat="server">
<Template>
<TR>
<TD nowrap="true"
valign="top" class="ms-authoringcontrols">
<SharePoint:FieldLabel
runat="server"/>
</TD>
<TD valign="top"
class="ms-authoringcontrols">
<SharePoint:FormField
runat="server"/>
<SharePoint:FieldDescription
runat="server"/>
</TD>
</TR>
</Template>
</SharePoint:RenderingTemplate>

After this modification and an IISRESET the pages that did not work, loaded successfully. But the labels for the property names were missing as shown below:

clip_image002_thumb

Of course it is not the best, as user would like to know which property do they modify.

Based on the PropertyIterator template we assumed, that there must be a description field too (see the FieldDescription control in the template above).We have not used that kind of field for the custom properties, and I think it is a not well-documented one, but we tried it and it worked:

<PropertySchema>
<Fields>
<Field Name="ErrorMessage"
DisplayName="Error Message" MaxLength="255" DisplaySize="25" Type="Text"
Description="Error Message">
</Field>
<Field
Name="InvalidLengthMessage" DisplayName="Invalid length message" MaxLength="255"
DisplaySize="25" Type="Text" Description="Invalid Length
Message"
>
</Field>
</Fields>
</PropertySchema>

If we set the Description attribute value to be the same as the DisplayName attribute, then the result is almost the same, as we hoped it to be:

clip_image004_thumb

If we go one step further, and rearrange the controls in the PropertyIterator template like this:

<SharePoint:RenderingTemplate ID="PropertyIterator" 
runat="server">
<Template>
<TR>
<TD nowrap="true"
valign="top" class="ms-authoringcontrols">
<SharePoint:FieldDescription
runat="server"/>
</TD>
<TD valign="top"
class="ms-authoringcontrols">
<SharePoint:FormField
runat="server"/>
</TD>
</TR>
</Template>
</SharePoint:RenderingTemplate>

then the description label will appear in the place of the property name, and the result is about matching to the one, that the original version should be:

clip_image006_thumb

Don’t forget to run IISRESET after modifications in the DefaultTemplates.ascx or in the field definition XML file.

Important remark: Altering DefaultTemplates.ascx migth not be a supported action, so it is better to create a separate file in the TEMPLATE\CONTROLTEMPLATES folder, for example call it PropertyIterator.ascx, and copy the headers and the PropertyIterator template from the DefaultTemplates.ascx, and make the modifications on this template. Altered version in the separate file will override the template in the DefaultTemplates.ascx.

UPDATE: 03.12.2009: For those of you who have not heard about that, there is a hotfix for this issue that is included in the "Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): August 25, 2009". Thanks to Geert van Raaij on the MSDN threads referenced above for sharing the link. There were rumors we heard from MS guys at the beginning of October that the bug is fixed in the latest cumulative patch, but they did not share the information where one can get that from.

Advertisements

1 Comment »

  1. […] parameterize per list on the admin user interface through the custom field properties (despite the issues with these properties) when creating the field for the list or for the web, or from code using the same custom […]

    Pingback by Custom field types as an alternative way for list item event handling in SharePoint « Second Life of a Hungarian SharePoint Geek — December 3, 2009 @ 01:33


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: