SPContext.Current.FormContext.OnSaveHandler不從自定義字段類型控件中觸發

Question

我遇到了與上述完全相同的問題here。不幸的是，因爲我沒有50分，所以我不能評論它，所以我必須創建一個新的重複問題。

我的意思是它不是「100％完全」像其他人的問題，因爲對我來說問題存在於編輯窗體上，我使用自定義窗體和字段的組合。但是我在現場級別添加了自定義保存事件處理程序，該處理程序是由該人在this網站所做的每個建議＃2。我還應該注意到，當我創建一個沒有任何自定義表單或內容類型的新文檔庫並直接使用自定義字段時，事件處理程序也不會觸發。但是，如果我創建一個新的常規SharePoint列表並添加自定義字段，那麼OnSaveHandler會觸發！我所以我不太清楚它爲什麼在文檔庫中不起作用，但它在列表中起作用，因爲我覺得自定義字段的美妙之處在於它們獨立於其他所有東西運行。也就是說，即使我用我的Edit Form或其他控件做了些什麼，因爲我將自定義方法附加到我的自定義字段的OnInit方法中的SPContext.Current.FormContext.OnSaveHandler，那麼應該激發無論什麼！即使在第一次加載該字段時，我實際上也會看到事件在調試器中被連接起來。在調試模式下，我在下面的「if」語句旁邊有一個斷點，它會觸發該斷點，這意味着當FormContext.OnSaveHandler被觸發時，我的方法應該會觸發。

protected override void OnInit(EventArgs e) 
{ 
    base.OnInit(e); 

    if ((SPContext.Current.FormContext.FormMode == SPControlMode.New) || (SPContext.Current.FormContext.FormMode == SPControlMode.Edit)) 
    SPContext.Current.FormContext.OnSaveHandler += new EventHandler(MyHandler); 
} 

有什麼想法？建議？

謝謝！

更新＃1：後一點疑難解答我是能夠推導出在我的自定義字段中的事件處理程序被解僱但在常規列表和不文檔庫使用時才！在常規的SharePoint列表中，不僅SPContext.Current.FormContext.OnSaveHandler被觸發，而且自定義字段的值也被保存。

請注意，將數據保存回繼承自SPFieldText的自定義字段時，值（即json數據）在列表視圖中顯示爲#VALUE！，我覺得有點奇怪。我的意思是它能夠正確讀取存儲在字段中的json數據，因爲它顯示在編輯表單中很好。但由於某些原因，SharePoint僅將其顯示爲＃VALUE！列表視圖中的。

Answer 1

因此，在經歷了許多令人沮喪的時間之後，它似乎在使用文檔庫中的自定義字段時會出現幾個問題。

1. 您不能以任何有意義的方式使用它們，並期望在使用自定義上載頁面時保存數據。換句話說，如果您想創建自己的自定義上傳頁面，該頁面將文件上傳輸入字段和瀏覽按鈕與嵌入ListFieldIterator中的自定義字段一起使用，那麼將不會節省值。這是事實！原因是上傳文件和創建初始ListItem以及生成其ID值的操作發生在與ListItem EventReceiver相關的異步上。那麼這到底意味着什麼？這意味着當您嘗試訪問ListItem的Event Receiver中ItemAdded方法的SPItemEventProperties參數中存儲在自定義字段中的值時，所有這些值都將爲null，因爲當前SPContext完全不知道這些值的存在字段和它們各自的值，因爲與初始文檔上傳相關的所有事件都是以不同的線程異步執行的。相反，當自定義字段試圖將自己「保存」回到新上載的文檔時，SPField.ListItem的文檔ID仍然設置爲零，因爲這些自定義字段是......您猜對了，在不同的線程中執行，而不是「與產生新文檔ID的上傳事件同步「。雖然我已閱讀了關於此問題的幾種不同的解決方法，但它們中沒有一個似乎起作用，或者它們非常複雜，或者要求您放棄使用自定義字段，這不是真正的解決方法，而更像是「拋出毛巾」。一個建議是簡單地通過添加「Synchronous」條目來更新EventReceiver的Elements.xml文件，以強制事件同步發生而不是異步發生。起初我認爲這太容易和太好了，以至於不真實。事實證明，我是對的。 :)
2. 您不能在自定義控件中嵌套自定義ListFieldIterator，並期望自定義字段保存它們包含的數據。您必須直接在您的表單模板中使用ListFieldIterator。期！如果您嘗試在自定義控件中使用您的自定義字段來包裝ListFieldIterator，那麼結果將非常令人沮喪。

作爲一個側面說明，一旦該文件已被上傳和ID已經被創建，你CAN將數據輸入到在編輯表單自定義字段和值WILL保存，因爲現在你的代碼實際上能夠引用ListItem的ID值，因爲ListItem已經存在於列表中。同樣，這與自定義上傳表單相反，因爲您尚未實際上傳文檔，因此ListItem的ID尚不存在。

我真的希望微軟能夠提供某種更新，讓開發人員能夠解決這個問題，並且我認爲很明顯，他們知道這是他們第一次發佈SharePoint時的問題，這就是爲什麼文檔庫「新窗體」的默認行爲是向用戶顯示一個獨立的上傳窗體，然後將用戶重定向到編輯窗體，以避免所有這些。當然這會讓希望允許用戶上傳文檔並在同一屏幕上輸入數據的開發人員在使用自定義字段時無需站立。你唯一的選擇是使用自定義表單，並以編程方式設置所有的字段值，併爲所有不同的字段和佈局可能性的每個單一排列添加噸和大量的條件邏輯，但這是一個完整的其他動物，肯定會打敗整個原因微軟首先創建了自定義字段的概念！