Why does the FileUpload control get bound to the current list item in a custom list EditForm?

Question

I've written a custom edit form for a list which means I lose certain out of the box capabilities such as Attachments as it was part of the out of the box form. The way I have implemented the form is by writing a custom visual web part using ASP.NET and C# code behind and then during deployment I hide the existing edit web part in the EditForm.aspx page and then add my web part to it.

The way I have developed the form is with a proper separation of concerns where my form really doesn't know anything about SharePoint and it just passes a data object to a datamanager object that then writes the data to SharePoint.

The problem comes in with the attachments form that I wrote. What I found is that SPContext.Current.ListItem.Attachments immediately contains the file in the FileUpload control upon post back. I did not have to write any code for this to happen - just trigger a postback while a file is selected in the control.

In most cases I can just ignore the fact that this happens and everything works fine because I never actually update that instance of the list item. But in some edge cases such as uploading a file where an attachment with the same name already exists, the form blows up without even touching my code.

I also found that there is an AttachmentsControl in the SPContext.Current.FormContext.FieldControlCollection and removing this in every Page_Init event of the UserControl doesn't help the issue at all.

The reason I want my form within the context of the list item is so that all of the out of the box tool bars / ribbon / context menus / etc. still properly link to the form. I could redirect from the edit form to an out of context page with my web part on it, but this seems hackish and unnecessary (not to mention just bad coding).

Does anyone have any insight on why this behavior is happening and how I can work around it? It seems like very bad design for any list form to automatically hijack a control for its own use like this. I feel like SharePoint should have its own control and just leave the ASP.NET control alone but that seems to not be the case.

Answer 1

On a standard list form if an attachment with the same name was added multiple times. If the item will be stored the form throws an exception, that one of the attachments was added multiple time and prevent from adding the item.

In your case you override this exception, which causes that no attachments are available when you try to store the list item. To avoid this behavior you need to manually check if a attachment was added multiple times otherwise you will always fail.

You need to remove the default NewForm web part instead of hiding it. Then the exception won't be raised and you are able to get the attachments.

Answer 2

If you attach an event handler to the itemAdding event does it fire on the error conditions? You might be able to use that to run some custom code to either handle the event, or possibly just suppress the system system error message and provide your own nicer one.