SPContext.Current.FormContext.OnSaveHandler Not Firing from Custom Field Type Control

Question

I am having the exact same problem described here. Unfortunately because I don't have 50 points yet I can't comment on it so I have to create a new duplicate question.

I mean it's not "100% EXACTLY" like the other guy's problem because for me the problem exists on the Edit Form and I'm using a combination of custom forms and fields. But I am adding the custom save event handler at the field level per suggestion #2 made by the guy at this site. I should also note that when I create a new Document Library without any custom forms or Content Types and just use my custom fields straight-up, the event handler also does not fire. If however I create a new regular SharePoint list and add the custom fields then the OnSaveHandler DOES fire! I So I'm not quite sure why it doesn't work in Document Libraries but it does work in lists because I was under the impression that the beauty of custom fields was that they operate independently of everything else. Meaning, even if I was doing something wonky with my Edit Form or some other control, since I am attaching my custom method to the SPContext.Current.FormContext.OnSaveHandler in the OnInit method of my custom field then that should fire no matter what! Even when the field is being loaded for the first time I actually see the event being wired up in the debugger. In debug mode I have a breakpoint next to the "if" statement below and it hits that breakpoint which means that when the FormContext.OnSaveHandler is triggered my method should fire.

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);
}

Any thoughts? Suggestions?

Thanks!

UPDATE #1: After a little troubleshooting I was able to deduce that the EventHandler in my custom field was being fired but ONLY when used in regular lists and NOT Document Libraries! In regular SharePoint lists not only is the SPContext.Current.FormContext.OnSaveHandler being fired but the values from the custom fields are being saved as well.

As a side note, when saving the data back to my custom field that inherits from SPFieldText, the value (which is json data) displays in the list view as #VALUE!, which I think is kind of weird. I mean it's able to read the json data that's stored in the field correctly because it shows up in the Edit Form just fine. But for some reason SharePoint just displays it as #VALUE! in the list view.

Answer 1

OK, so basically it comes down to this: When using custom fields in a ListFieldIterator you MUST embed the ListFieldIterator DIRECTLY in the Form Template.

You cannot "wrap" a ListFieldIterator in a user control and then embed that user control in the Form Template. You can try and the fields should display just fine but none of the data will be saved.

As for custom fields in general, they are all very nice and good when using them with regular SharePoint lists. But when it comes to Document Libraries...that's where things get a bit dicey. If you want to create your own custom upload page that includes not only the file upload field and accompanying "Browse" button but also your own custom fields as well, then I'm afraid you're going to be very disappointed. The issue comes down to the fact that the whole file upload process happens prior to the actual ListItem creation and (here's the really important part) it also happens to execute asynchronously.

Read that last sentence again just to make sure it sinks in.

If you create a ListItem EventReceiver and attempt to access the SPItemEventProperties in the ItemAdded method you'll quickly discover that all of the values for your custom fields unfortunately evaluate to NULL. It's not that data you entered into the input fields has disappeared, rather it's that the data from those fields is not actually available to the ListItem's EventReceiver because it's executing "asynchronously" in a totally separate thread. Later on after the initial upload/save process completes you can see that your data still exists in your fields and the values won't be NULL. But if while in debug mode you check the value of the current ListItem's ID in the UpdateFieldValueInItem() method you'll see that it is still equal to the default value of zero!

Why is this the case? Because (as mentioned previously) the code that handles all of the objects related to the custom fields executes in a totally different thread than the code which handled the initial file upload.

In simple English this means that you have two sections of code that operate independently and have absolutely no knowledge of one another.

Of course this is only an issue during the initial upload of the file since the ListItem has not yet been created. Once the file has been uploaded and the ListItem HAS been created then you can save your custom field values back to the actual ListItem. This technically occurs as an "update" to the newly created ListItem and is NOT part of the initial ListItem creation.

One Final Note: If you think about it, there was a reason why Microsoft separated out the default OOTB New File Upload form and didn't give users the option to put everything onto one single New Form like a regular SharePoint lists uses. After uploading a new file using the default upload form you'll see that upon completion of the upload the user is actually redirected to the Edit Form page which essentially means that Microsoft chose to address the asynchronous nature of the file upload process by avoiding it entirely.