Mark Anderson published today an article on his blog concerning an issue that currently exists in Office 365 and is called “Office 365 Update Changes ‘Display Name’ on Required Fields”. In this article he described that the rendering of fields recently have been changed in Office 365. I will take a look what can be done to solve this probably.

The cause of the problem

The title attribute of list fields have been widely use to customise forms in SharePoint using JavaScript, JQuery or SPServices. I used this attribute sometimes too do address fields by the display name. But somehow I always had a bad feeling about this. Why? Well, the ID attribute of the field is the only real unique identifier in the form. The downside using the ID is that you need to have some information about the field to generate the ID. But I will explain this later.
What the update recently in Office 365 did was to change the rendering of the field. Previously it look like this:

Now it has changed to this:

As you see now the title has additional parts such as required or field. This means that you haven’t in this attribute the display name of the field alone and you will fail if you query by title.

Safer approach to request fields

As mentioned before the ID property is the only one that is unique in the whole page. The ID is formatted in the following form:
Field name + ”_” + Guid of the field + ”_$” + Type of the field.
As seen in the previous section the ID looks like this:
Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField
So if you like to be absolutely sure and like to generate this ID by yourself you need to do a request to the list and read the fields. The you will be able to find the name by the display name, the id and the type. This will make some lines of code that you can reuse in your projects. I haven’t seen any ready made code yet but I’m sure it can be found somewhere over the internet. (If you have would be great to post that in the comments)
I looked into this problem and what I found was that SharePoint does that job for you and stores it on the form in the JavaScript variable “WPQ2FormCtx”.

Console output of WPQ2FormCtx Object

Console output of WPQ2FormCtx Object

This context is somehow new in SharePoint 2013 and Office 365 This somehow represents the so called form context with a lot of information. Also included in this variable is the list schema which we can use without loading any additional information from the list.
So what I did is that I created a small javascript object that loads the information and allow me to generate the id of the field. The tricky part i currently not have implemented is the type part because this is a little bit tricky and the value changes with the different configurations of the fields. I hope that the following code give you an example how this works.

To this script the last part needs to be added to be 100% sure. Think about the fill in option for example this will start with the same id but I’m sure there will be added a special type.

Field after update via JS

Field after update via JS

As you see the value was written to the form

A Look to the future

I will never use the title field again. I write this now 100 times to keep it in mind. But not here in this blog post. In future I will reuse my little helper object for a simple reason. If Microsoft changes the format of the ID attribute I only need to change it at a central location instead of search and replace all my jQuery / JavaScript code.
Convenience is not everything better go an extra mile to be safe.

Let’s jump right into the topic how it is possible to pass data to a modal dialog. On first sight it looks like a complex task but after you read this article you will get an overview how it works. In this simple scenario I use a HTML Form web part with a text box and a hyperlink. The value then should be passed to the new form dialog of a custom list called “Cars”.

Opening the modal dialog

In general there are two ways to open a modal dialog.  The asynchronous and the synchronous way to open a modal dialog, but here I use the synchronous way to keep the code simple.

The setup for this scenario is simple. First I created a custom list named “Cars” and this list has nothing more than the default title field. After that I added a new HTML Form Web Part to the landing page of my demo site. Then I added a simple form to the web part. It consists of a textbox with the id “newcar” and a hyperlink with the id “create” to create a new entry. This form also loads JQuery from the CDN and the custom script that is needed to pass the value of the input field to the modal dialog.

html form web part

HTML Form web part that should pass the values to the modal dialog

The code of the form looks like this:

 

First the click event on the hyperlink needs to be registered to open a modal dialog. Then the data from the textbox needs to be passed to the title field of the modal dialog.

So far so good this all no rocket science but how do we get the data to the form? Therefor a little trick is needed. The function “SP.UI.ModalDialog.get_childDialog()” will return the last loaded modal dialog. The modal dialog object returned by this function has a special property named $c_0. Once the dialog has been loaded it contains the content of the modal dialog. All that needs to be done is to recheck this property during the loading of the dialog. This can be accomplished with a simple recursive call that pauses for 100 milliseconds, in my case, and check the property again. If this is set then the loading has been completed.

After the content has been loaded all that needs to be done is to parse the property to a JQuery object. Once it is accessible in JQuery the value of the form web part input field can be added to the title field of the new form. The result can be seen in the following screenshot.

modal dialog after the values have been passed

Modal dialog after the values have been passed to the modal dialog

Further user experience enhancement

A nice additional feature when data will be passed to a modal dialog is to tell the user to check the values. This can be done using the page status bar for example. The problem here is that the status bar cannot be enabled with the SharePoint function SP.UI.Status.addStatus.

Previously we already loaded the content to a JQuery object, so we can do further manipulation of the output of the modal dialog. SharePoint renders on default a placeholder for that page status with the id “#pageStatusBar”. The code to show the page status looks like this:

At the end I forced the modal dialog to resize itself to avoid possible scrollbars.

Modal dialog with page status

Modal dialog with page status

If you have any suggestions or question please feel free to provide some feedback. As always you can download the html form web part in the link below.

Download the web part: Modal dialog part 1

Please make sure to change the path of the new form

You might know this situation, when you like, for example, pass a query string to a modal dialog to preselect values in a list form. With SharePoint Designer or custom development this is an easy task. What if you like to customize the form without permanently modifying the form itself?

In this post series I will show my newly discovered way to have better control over forms.

How come? Well over the last week I had the request once again, to pre-fill a list form with values from another list. So I was thinking to myself that there must be a better ways to do this task. Lucky me I found one.

In the next posts I will first introduce you to the basic concept of this kind of customization.

The series is planned to contain the parts:

In all these parts the customisations will be done using JavaScript / JQuery and our best friend SP Services, when it comes to SharePoint customization. In all those part I leave the form dialogs untouched. No additional web part on the forms will be used.

Hope you enjoy this series and maybe I will add some additional chapters at the end.

Since SharePoint 2010 was introduced there are much more ways to customize forms for list and document libraries. In most cases there is only the simple requirement to hide fields or have better control over them on lists and content types. SharePoint 2010 is the same way limited for hiding fields like it was in MOSS 2007. For advance control it was always necessary to code those fields. So first let’s take a look at how you can controls fields on the list using the normal settings dialog. The base setup in this test is a custom list called “List” with a new column called “NewColumn” which is of type single line of text.

There are no settings available where you can control where the fields should be appearing. The options to hide a field form certain forms are even not available in SharePoint. So the only way to remove the fields from NewFormDialog for example will be to set up a custom list form. No not at this stage.

When the management of content type is enabled to the list using some advance settings will come up to the fields. This can be done in the list settings:

  • “Advanced settings”
  • “Allow management of content types”
  • “Yes”

Behind ever list and library there is a content type assigned. For my custom lists this is the “Item” content type. After selecting this content type there is the “NewColumn” I created available too. On the column the following view options can be selected.

Required optional or hidden is good but won’t help in most cases. So what now? Create a custom list form? No, this is not needed.

SharePoint developer might find SPField Object from the server object model. So if a developer creates a custom content type the following options can be selected in CAML Definitions or as properties using object model.

  • ShowInDisplayForm
  • ShowInEditForm
  • ShowInListSettings
  • ShowInNewForm
  • ShowInVersionHistory
  • ShowInViewForms

I think the names of those properties are self-explaining. Is there coding needed to use those properties? Yes it is but not as a WSP. This field can set using PowerShell the following example demonstrates how to set those properties by a simple script which only opens the list using object model and sets the values, which are basically Boolean values. I use simply 0 and 1 values to set.

0         enables this property

1         disable this property

So for hiding our column in the new form dialog we just simply need to set the value of ShowInNewForm to false or 0.

So how does it look after executing the script:

NewColumn Hidden

NewColumn is hidden on NewForm but still avaliable on EditForm.

Conclusion:

I actually can’t say what the reason is behind those properties are available using object model but not be available using the interface or SharePoint Designer. Those properties will give power user better control over their fields and will not require custom list forms using SharePoint Designer or InfoPath Forms for every simple field hiding. Those properties are not new they were still available in Moss 2007. Might this will be supported by SharePoint 2013 or 2014.