1

I am developing a SharePoint (2007) document library item event receiver to force the user to click on the [Cancel] button instead of the [OK] button in the Edit Form (EditForm.aspx), since clicking on the [OK] button is perceived as an update, even if none of the values are modified. In order to achieve this, I am overriding the itemUpdating method with the following code:

bool propertiesChanged = false;
foreach (SPField field in properties.ListItem.Fields)
{
    if (field.Hidden || field.Sealed || field.ReadOnlyField)
    {
        continue;
    }

    if ((properties.BeforeProperties[field.Title] == null ^ properties.AfterProperties[field.Title] == null)
        || (properties.BeforeProperties[field.Title] != null
            && properties.AfterProperties[field.Title] != null
            && !properties.BeforeProperties[field.Title].ToString().Equals(properties.AfterProperties[field.Title].ToString())))
    {
        propertiesChanged = true;
        break;
    }
}

if (!propertiesChanged)
{
    properties.Cancel = true;
    properties.ErrorMessage = "If you did not intend to modify this item, please click on your browser's [Back] button and press [Cancel] instead of [OK].";
}

The document library contains a date field, a couple of check-box fields and a couple of drop-down/choice fields. But this effort is riddled with challenges causing me concern that I may be in the wrong path.

  • I wanted to access the column values using the internal name of the field (and not the display name), but I kept getting null values when employing the internal name with the code properties.BeforeProperties[properties.ListItem.Fields[field.Title].InternalName]
  • For a check-box, properties.BeforeProperties yielded 0 and properties.AfterProperties yielded false, thereby causing the code to indicate that a property has changed, when actually it did not (since 0 and false are semantically the same)
  • In consecutive runs, fields with textual values that already have some values have an empty BEFORE value and actual AFTER value. This behavior is alternative (and very odd!)
  • With all the odd behavior I am encountering, propertiesChanged is always true, so the code never executes the Cancel/ErrorMessage block at the end

I need to understand what I am doing and fix it. MSDN documentation is a bit lacking in this area, with no good examples or best practices/recommendations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.