So, I’m working on a custom field definition for SharePoint. My field has a few custom properties that you need to fill in when you create it. However, after creation, those fields were empty – they were simply never set. You could then update them, and that worked fine, but creation was broken.
The code I’d inherited was trying to solve this problem (it’s a known issue) this way – which is a bit ugly. It also holds memory for the Dictionary of values that, as far as I could see, was only being freed on IISReset. Yuck. And it didn’t work in our code, despite matching the example in that thread quite closely.
Fortunately, I came across a neat post on Gunnar Peipman’s blog – Temporary Solution for GetCustomProperty an SetCustomProperty Errors. I don’t like using reflection to invoke the methods I need to use, but at least it’s a solution, even if not ideal. And it works!
Please go to Gunnar’s post – but just in case his blog goes down, I’m going to shamelessly plagiarise his code below…
Thanks Gunnar! Continue reading “Inconvenient GetCustomProperty and SetCustomProperty”
So, I’ve been working with a custom field type recently. It’s quite a complicated one – I’ll not go into details – but we did hit a problem with it. When a Word document was opened it would try to display our field in the Document Information Panel, which isn’t really possible, and caused Word to die in a horrible fashion. I forget the exact error we were getting, but it was something to do with the XSN being invalid.
What we really needed was a way to set that the property wasn’t to be shown in the Document Information Panel. However, there is no easy way of doing this with a purely programmatically created column. There are properties on the SPField object that can be accessed programmatically, and the CAML for a FieldRef can set ShowInFileDlg – but there isn’t an obvious way to set this value from C# code.
Naturally, that’s what we wanted to do. Well, there is a combination approach – the SPField.SchemaXml property allows us to get/set the CAML that defines the field.
So, I came up with this static function:
static void SetShowInFileDlg(SPField f, bool value)
XmlDocument fieldSchemaXml = new XmlDocument();
XmlAttribute attr = fieldSchemaXml.CreateAttribute("ShowInFileDlg");
attr.Value = value.ToString().ToUpper();
XmlNode fieldXmlNode = fieldSchemaXml.SelectSingleNode("Field");
XmlAttributeCollection fieldAttributes = fieldXmlNode.Attributes;
f.SchemaXml = fieldXmlNode.OuterXml;
I’m not sure what happens if you’re trying to update an already widely used column – will it update all content types that that column – but this worked for us.
While working on pre-filling ListItem fields on an item, I became a bit puzzled. The SPItemEventProperties.AfterProperties collection is a dictionary which can contain the named value for one of the fields of the item. In other words, if we wanted to set a value “Tax Area” to “Europe” we’d do:
properties.AfterProperties["Tax Area"] = "Europe";
In our case, however, we didn’t know what these properties were before hand. Rather, we were ‘inheriting’ values from a parent folder. Thus, we were going to use the parent folder’s SPField object for each field to define the value. I started out using:
properties.AfterProperties[parentField.Title] = parentItem[parentField.id];
But is Title the right property to use? Well, having looked through a number of blog posts, this seems to be the subject of some confusion.
At first Title is okay to use. However, you can change the display name of the field. For example, we could change our field’s Title to ‘Tax Region’ – but we still need to use ‘Tax Area’ in our AfterProperties collection.
So, InternalName is the right property of the SPField to use – but there is a hiccup. The InternalName is encoded –
Tax_x0020_Area – so you have to unescape it like I’ve talked about before.
The summary is, then, use the unescaped InternalName in your AfterProperties collection.
Next task on my prep – create a list programmatically. Then I want to add some columns to it, and show these on the default view. Actually, it’s mostly pretty easy (apart from that last part). Continue reading “WSS Practice: Create a list, columns and view programmatically”