Microsoft.SharePoint


SPFieldComputed Class (Microsoft.SharePoint)
Represents a computed field, which is a field that depends on another field for its contents.

Namespace: Microsoft.SharePoint
Assembly: Microsoft.SharePoint (in microsoft.sharepoint.dll)
Syntax
Visual Basic (Declaration) 
<SharePointPermissionAttribute(SecurityAction.LinkDemand, ObjectModel:=True)> _
<SharePointPermissionAttribute(SecurityAction.InheritanceDemand, ObjectModel:=True)> _
Public Class SPFieldComputed
    Inherits SPField
Visual Basic (Usage) 
Dim instance As SPFieldComputed
C# 
[SharePointPermissionAttribute(SecurityAction.LinkDemand, ObjectModel=true)] 
[SharePointPermissionAttribute(SecurityAction.InheritanceDemand, ObjectModel=true)] 
public class SPFieldComputed : SPField
Remarks

If you set properties of the SPFieldComputed class you must call the Update method for changes to take effect in the database.

An SPFieldComputed object can be rendered through the ComputedField server control.

The SPFieldComputed class corresponds to the Computed data type that is specified through the Type attribute of the Field element.

NoteNote:

Windows SharePoint Services 3.0 does not support inheriting from this class.
Inheritance Hierarchy
System.Object
   Microsoft.SharePoint.SPField
    Microsoft.SharePoint.SPFieldComputed
Thread Safety
Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
See Also
Tags :


Community Content

Thomas Lee
Updating SPField.SchemaXml causes an update to the WSS database and does not update properties.
The following statement is not interely correct:

"If you set properties of the SPFieldComputed class you must call the Update method for changes to take effect in the database."

Similarly to the behaviour described in the linked MS KB article (http://support.microsoft.com/kb/555293), any change to SchemaXml will cause an internal update and a further call to Update() will undo those schema changes.

A valid reason for calling the set accessor of SPFieldComputed.SchemaXml without calling Update() could be setting the field DisplayPattern through code: 

field.Description = "This is my custom list column with an edited DisplayPattern";
// Parse the Schema XML string so we can edit it. The get accessor has no volatile behaviour.
XElement schema = XElement.Parse(field.SchemaXml);
XElement displaypatt = schema.Element("DisplayPattern");
if (displaypatt != null)
displaypatt.Remove();
// substitute our own displaypattern. Here we are working with a separate XElement object, not
touching SPFieldComputed.SchemaXml.
displaypatt = XElement.Parse(@"
@"<DisplayPattern>
<HTML>
<![CDATA[<img src=""_layouts/images/my_custom_image_]]>
</HTML>
<Switch>
<Expr>
<Column Name=""ContentType""/>
</Expr>
<Case Value=""Document"">
<HTML><![CDATA[docicon]]></HTML>
</Case>
<Case Value=""Task"">
<HTML><![CDATA[taskicon]]></HTML>
</Case>
<Default>
<HTML><![CDATA[default_icon]]></HTML>
</Default>
</Switch>
<HTML><![CDATA[.png"">]]></HTML>
</DisplayPattern>";

schema.Add(displaypatt);
// Set the SchemaXml, this will cause an internal update.
field.SchemaXml = schema.ToString();

// don't call this! Your schemaXml will revert to the previous value.
//field.Update();


Page view tracker