使用Vista时无法在ItemAdded事件上更新文档属性

We are trying to create a custom event handler that would fire on ItemAdded event. The event handler then updates the document with a unique ID value to a column in this document library.

我们正在尝试创建一个自定义事件处理程序,它将触发ItemAdded事件。然后,事件处理程序使用唯一ID值将文档更新到此文档库中的列。

Our solution works fine, except when a user on Vista is trying to save a new document from Office 2007. In this scenario the document is stored to document library but Unique ID column is empty, and there is no exception.

我们的解决方案工作正常,除非Vista上的用户尝试从Office 2007保存新文档。在此方案中,文档存储到文档库,但唯一ID列为空,并且没有例外。

Vista Users can upload document(s) to library without a problem. Everything else works fine on XP and Win2k3 operating systems.

Vista用户可以毫无问题地将文档上传到库。其他一切在XP和Win2k3操作系统上运行良好。

Has anyone seen something similar, and what might be the problem here? To demonstrate the problem we are using DateTime.Now as unique ID.

有没有人见过类似的东西,这可能是什么问题?为了演示这个问题,我们使用DateTime.Now作为唯一ID。

 using Microsoft.SharePoint;

 public class TestReciever : SPItemEventReceiver
 {

     public override void ItemAdded(Microsoft.SharePoint.SPItemEventProperties properties)
     {

         try {
             DisableEventFiring();

             properties.ListItem("UniqueID Column") = DateTime.Now.ToString();
             properties.ListItem.SystemUpdate();

             EnableEventFiring();
         }
         catch (Exception ex) {
             // handle exception
         }


     }
 }

3 个解决方案

#1

We have noticed exactly the same thing happening. When the 2007 doc is added to the library, the properties from the list are added to it (blank).

我们注意到发生了同样的事情。将2007 doc添加到库中时,列表中的属性将添加到其中(空白)。

Then the (synchronous) event handler is called, updating the list with the correct values for the UniqueID column.

然后调用(同步)事件处理程序,使用UniqueID列的正确值更新列表。

Then the inbuilt property mapping to 2007 docs kicks in and overwrites your values with those stored in the 2007 doc (not raising an item updated event again).

然后映射到2007文档的内置属性启动并使用存储在2007 doc中的值覆盖您的值(不再提高项目更新事件)。

This means that the list now has a blank for your column.

这意味着列表现在的列空白。

If you change to an asynchronous event you may see what we did and that the slight delay for asynchronous meant that the property mapping to 2007 docs happened first (we think) meaning the value was stored correctly.

如果您更改为异步事件,您可能会看到我们所做的事情以及异步的轻微延迟意味着首先发生到2007 docs的属性映射(我们认为)意味着值已正确存储。

It is possible to break the property mapping between the list and office, but that is only a workaround.

可以打破列表和办公室之间的属性映射,但这只是一种解决方法。

I cannot for the life of me find where this info is on an MS site, but it is a known problem. Perhaps you can hang in there for SP2 (may even be fixed in SP1, but am unsure).

我不能为我的生活找到这个信息在MS网站上的位置,但这是一个已知的问题。也许你可以在那里挂起SP2(甚至可能在SP1中修复,但我不确定)。

#2

At the end we contacted Microsoft and they provided us with the following workaround solution. The key here is to delay item update in a separate thread.

最后我们联系了Microsoft,他们为我们提供了以下解决方案。这里的关键是在单独的线程中延迟项目更新。

private Guid listID;
private Guid itemID;
private Guid siteID;



public override void ItemAdded(Microsoft.SharePoint.SPItemEventProperties properties)
{
    DisableEventFiring();

    item = properties.ListItem;
    listID = properties.ListId;
    itemID = properties.ListItem.UniqueId;
    siteID = properties.SiteId;

    Threading.Thread setDocumentInternalIDThread = new Threading.Thread(SetInternalID);
    setDocumentInternalIDThread.Start();


    EnableEventFiring();
}


private void SetInternalID()
{
    try {

        Threading.Thread.Sleep(10000);
        using (SPSite site = new SPSite(siteID)) {
            using (SPWeb web = site.OpenWeb()) {

                SPList list = web.Lists(listID);
                SPListItem item = list.Items(itemID);

                item(Common.CustomID) = Common.GetAlphaPrefix() + Common.GetDocNumber();
                item.SystemUpdate();
            }

        }
    }
    catch (Exception ex) {

        Log(ex.Message);
    }
}

#3

Another workaround is to set the custom field that is being updated in the event receiver to be read only (set the fields ReadOnly property to TRUE). This has a few pros and cons. This is ideal for a unique id solution, because there is no way for the user to modify the value. However, the field is hidden to the UI, so managing it becomes more troublesome, and the field can't be used in labels, or quick parts. You can set the ShowInDisplayForm property of the field to TRUE to have the field display in the view form, but not the edit form. The field can also be added to your views. This is the best workaround I have found for this issue to date.

另一种解决方法是将事件接收器中正在更新的自定义字段设置为只读(将字段ReadOnly属性设置为TRUE)。这有一些优点和缺点。这是唯一ID解决方案的理想选择,因为用户无法修改该值。但是,该字段对UI是隐藏的,因此管理它变得更麻烦,并且该字段不能用于标签或快速部件。您可以将字段的ShowInDisplayForm属性设置为TRUE,以使字段显示在视图窗体中,但不显示在编辑窗体中。该字段也可以添加到您的视图中。这是我迄今为止针对此问题找到的最佳解决方法。

This is an issue with Office 2007 and the WSS 3.0 xml parser. When the properties are promoted from the Office 2007 document, the parser attempts to assign document properties to the list properties in SharePoint (property promotion). The problem is that this event occurs after any ItemAdded, or ItemUpdated events, so the property gets overwritten with the value in the document, which is of course, blank. Microsoft has raised this as a bug, and I was hoping for a fix in SP2, but no such luck.

这是Office 2007和WSS 3.0 xml解析器的问题。从Office 2007文档升级属性时,解析器会尝试将文档属性分配给SharePoint中的列表属性(属性提升)。问题是此事件发生在任何ItemAdded或ItemUpdated事件之后,因此该属性会被文档中的值覆盖,这当然是空白的。微软已将此作为一个错误提出,我希望在SP2中修复,但没有这样的运气。

#1