Friday, 16 November 2018

Add File Name field to custom EditForm

It's been a while since I posted here. Maybe this is because I've now switched to using SharePoint Online, and I'm finding it needs fewer workarounds than SP2007.

Okay ... that sounds a bit unlikely.

So here's a challenge I had recently. One of my clients asked that they get a File Name edit field in a custom EditForm I'd created for a Document Library.

The out-of-the-box EditForm included a File Name field as standard.

Here's an example of how a standard EditForm presents its fields. Right at the top, labelled "Name" is the file name field. We can tell it's for a PDF, as Microsoft has helpfully rendered the file suffix outside the editable field.

It seems that Microsoft disable the File Name field in custom EditForms. So I Googled to find a solution. The only workaround I came across suggested that the File Name field could be added manually by pasting some code into the EditForm in SharePoint Designer.

<asp:TextBox runat="server" id="ff26{$Pos}" ControlMode="Edit" text="{@FileLeafRef}" __designer:bind="{ddwrt:DataBind('u',concat('ff26',$Pos),'Text','TextChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@FileLeafRef')}"/>

Except that this doesn't quite work.

Let me explain.

If you use the above code - pasted in to the second table cell in the new row you'd create to hold it - you get this result:

Spot the difference - this version, the custom EditForm with the above code added doesn't render the file suffix. A bit confusing for end users, I'm thinking.
For me this was a bit of a deal-breaker. Without the visual hint that the file suffix gives the end-user, I didn't think it was obvious what that editable field was doing. Even more alarming, end users might change the file name without realising what they were doing.

This would explain why Microsoft chose to exclude this feature from the custom forms. Except, in this instance, my client needed it.

So I took a look at some of the other fields in the code and figured out a solution. Well, more of a lucky guess, really.

But first, let me say this. Look at the ID value in the above code: "ff26". SharePoint uses these values to differentiate between input fields. If you have two fields with the same ID, you will get an error: "Unable to display this web part ..." or similar.

So first make sure that before you add any code to the EditForm page you've scrolled to the end of the form fields section and checked the ID value of the last row in the form. In my case, it had the ID value of ff25.

Then, because I could see that the code for all the other form fields began with:

<SharePoint:FormField ...

I thought I'd try that instead, and re-wrote the above line of code as this:

<SharePoint:FormField runat="server" id="ff26{$Pos}" ControlMode="Edit" FieldName="FileLeafRef" __designer:bind="{ddwrt:DataBind('u',concat('ff26',$Pos),'Text','TextChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@FileLeafRef')}"/>

Be aware that the attribute "text" isn't permissible in the SharePoint:FormField tag, so I used FieldName instead.

And it worked.

The File Name field rendered perfectly and even tagged on a file suffix after the text field.


Success ... those small alterations to the code cause the custom EditForm to render in exactly the same way as the out-of-the-box one.
I hope that's helped someone ...