5

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.

|improve this question
  • could you post at least some boiler plate code that has this issue. That way we can test different solutions instead of guessing :-) – Anders Rask Jun 5 '12 at 8:19
1
+200

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.

|improve this answer
  • On the standard list form there is no error until you actually hit submit. I cannot manually check because it happens immediately on postback without even reaching my code due to it being tied to the SPContext.Current.ListItem - I don't call any code that tries to update it. The only "checks" I could potentially do would be javascript which doesn't seem right to me. I should be able to handle this server side. – SpartanDonut Jun 5 '12 at 0:00
  • i.imgur.com/SXASi.png - Screenshot of multiple attachments with same name using out of the box form. Though now that I do it I see that SharePoint doesn't post back and when you click save its the same exact error I'm seeing so it would seem at least I'm replicating out of the box functionality, problem being my form posts back on more than just save. I still can't manually check against it though (server side) because my code won't even run before it throws the exception. – SpartanDonut Jun 5 '12 at 0:09
  • As you see you have only the local path to the attachments but not the attachments itself. This means that the files are still not uploaded to SharePoint. Before the form will be submitted to SharePoint, the attachments will be checked for duplicate filenames. If everything is ok then the files will be uploaded to SharePoint. If the check fails you won't get the files uploaded to SharePoint and there for you event can't check the files on the server side. – Stefan Bauer Jun 5 '12 at 5:20
  • In my opinion the only way is a custom attachments dialog and remove the default new form. Removing, not hiding of the default form, will avoid the attachment check made by SharePoint. This won't solve the problem with the duplicate filenames that cannot be attached to a SharePoint item. – Stefan Bauer Jun 5 '12 at 5:20
  • Well that was too simple. Removing the default form instead of hiding it did the trick. As soon as I did that my duplicate file name check kicked in and I avoided the nasty SharePoint exception. If you update your answer to this I'll mark it. Thanks for pointing out the obvious! I'm too used to doing custom SharePoint designer forms I guess. :) – SpartanDonut Jun 5 '12 at 13:47
0

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.

|improve this answer
  • 1
    The error occurs on ANY postback after a file with the same name as another is put inside the FileUpload control - I don't even have to attempt to save. On top of that if I put in a file that does not yet exist it will appear in the SPContext.Current.ListItem.Attachments but it won't actually save unless I tell it to. This being said, I don't think it's going to fire an Adding or Updating event because the attachments never actually gets saved / the item is never updated until I explicitly call SPListItem.Update() - error or not. I'll give it a shot though and let you know how it goes. – SpartanDonut Jun 4 '12 at 21:27

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.