Workaround for Multi-Value Fields Bug

Home » Workaround for Multi-Value Fields Bug

Tommy Valand posted on his blog yesterday and on the Notes 8.5 forum today a bug with multi-value fields. Basically save switches the output between a multi-value field and a semi-colon-separated string.

Coincidentally I was working on an XPages application today, with a keyword form, for which I needed a multi-value field. Not surprisingly, I got exactly the same output.

I don’t know if it’s something that’s slipped into 8.5.1 or something that’s been there since 8.5.0, but considering that it’s consistent and unlikely to be resolved within the timescales required by my app, I set about trying to get a workaround. And so here it is.

For your multi-value field(s), add this code to the querySaveDocument event of the DominoDocument data element. If you unsure where that is, you’ll need to go into All Properties, just here:

All Properties - Data - querySaveDocument

Enter this code, changing the component name and field name:

querySaveDocument Code

The first line puts the code into a variable called val. The second line explodes the value using the separator “;”. The third line calls currentDocument.replaceItemValue to set the value – @SetField doesn’t work and it also refreshes the page. You’ll notice we’re doing an @ReplaceSubstring. This is because the value, after first save, is (I think) an array. Basically, without this you get:

“[Test 1”

“Test 2”

“Test 3]”

Another caveat. This will not work if a new line separator. @Explode(…, @NewLine) splits the string at carriage returns and the letter “t” in Internet Explorer. I haven’t tested in other browsers, so cannot confirm or deny the same behaviour for those.

Leave your multi-value separator as “;” in the text field or textarea (I’m using the latter). This will ensure you get a semi-colon-separated list when you edit the document rather than a comma-separated list.

The code is attached.



After a night’s sleep, a couple of additional thoughts.

1) In theory, this should have no negative impacts once multi-value fields do convert their input consistently.

2) I haven’t investigated, but another option might be to add similar code on the Input Translation of the form, and set computeWithForm to onsave.


2 thoughts on “Workaround for Multi-Value Fields Bug”

  1. I have a similar problem, sadly this work around doesn’t help me.

    Simplified, I have a button that adds rows to a set of multi value fields. So to do that with JavaScript you would think that this would work:

    Array = DataSource.getItemValue( “FieldName” );

    Array.push( NewValue );

    DataSource.replaceItemValue( “FieldName”, Array );

    But no. If you hit the button a few times, what you end up with is this:

    [[[[NewValue],NewValue],NewValue],NewValue] etc x multiple multi-value fields

    getItemValue does not return an array. Well it does return an array, but it is just 1 element containing what looks like an array. (The undocumented getItemValueArray does exactly the same thing.) So, you would think that manually mangling that into a proper array would fix the issue, like this:

    Array = DataSource.getItemValue( “FieldName” );

    Array = Array.toString();

    Array = Array.replace( /[/g, ” );

    Array = Array.replace( /]/g, ” );

    Array = Array.split( ‘,’ );

    Array.push( NewValue );

    DataSource.replaceItemValue( “FieldName”, Array );

    But not quite. If you hit the button a few times you end up with this:

    NewValue, NewValue, NewValue, NewValue etc x multiple multi-value fields

    When this is expected:





    etc x multiple multi-value fields

    replaceItemValue does the exact opposite of getItemValue – it puts what looks like an array all into 1 element.

    One saving grace is that “classic” Domino can handle the result – so after you save it ends up displaying as expected. But while editing it looks like a dog’s breakfast.

    I’m happy for you Paul, good work. Just throwing this out there for anyone else with something closer to my situation. Here’s hoping 8.5.2 makes my situation better as well.

    (Should I try messing with the data source of my repeat to handle proper arrays as well as the results of this SSJS mess? I’m open to any more reasonable suggestions!)

  2. Brilliant Paul. I was surprised to find these problems still persist and your example is clean, clear and very helpful. Saved me a heap of time.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top