Michael Herman - Parallelspace

We use the following generic code for assigning the value of a field in a source list to the value of a field in a target list:

SPListItem oSourceItem = ...;
SPListItem oTargetItem = ...;

object oValue = oSourceItem[sSourceFieldName];
if (oValue == null)
{
    EMPTrace.WriteMessage(MethodInfo.GetCurrentMethod(), "FAILURE: '" + oTargetField.Type.ToString() + "': sSourceFieldName:'" + sSourceFieldName + "' is null");
}
else
{
    oTargetItem[sTargetFieldName] = oValue;
    EMPTrace.WriteMessage(MethodInfo.GetCurrentMethod(), "'" + oTargetField.Type.ToString() + "' value '" + oValue.ToString() + "' copied from '" + sSourceFieldName + "' to '" + sTargetFieldName + "'");
}

The above snippet works for all of the matching SPFieldType combinations except for the following:

In failing scenario, both the source and target fields are SPFieldType.Note items with multi-line and "Append Changes to Existing Text" enabled for the source (and destination) Note list item.

oValue is always being set to null.  What is special about fields that are SPFieldType.Note items with multi-line and "Append Changes to Existing Text" enabled.

Is there a reason or is this a bug

p.s. In a slightly different scenario where we set oValue to be a simple string, the assignment to the target Note field succeeds.  The problem has something to do with getting the "Note with Append" object from the SPListItem.Items collection.

 




Re: SharePoint - Development and Programming What is peculiar about copying a multi-line Note field type (with Append-enabled)?

Michael Herman - Parallelspace

I've learned a bit more about the cause of this problem ...hopefully the "right PM" will log this as a bug to be fixed as opposed to "working by design".

The original code snippet is part of an SPD custom WF activity that copies selected fields from a source list item to a target list item.

For testing, I've been using Edit Item on the source list item to trigger a change in the item to start the workflow.  Part of the root cause of the problem is that when you edit an item containing the multi-line Note field (with Append-enabled), the plain text control is empty ...i.e. it doesn't contain the most recent/current value of the multi-line Note field (with Append-enabled).  The control is not initialized with the current value of the Notes with Append field.

When you save the edited item, the field has no value and is saved with "no value" and when the WF activity tries to read this as the source item field, it is null ...as opposed to the most recent value of the field (which some argue should be null/empty string because that is the value that was in the Edit Item control when the item was saved).

This is totally inconsistent with the behavior of all of the other SPFieldTypes.