Domino Auto-Trimming Multi Value Fields
It's funny with Domino how I sometimes think I know something about the way it behaves only to find I'm wrong. Whether I was always wrong or the behaviour has changed I'm never quite sure. What I'm about to describe is a case in point.
Here's my long-running assumption: If you have a multi-value field separated by, say, semi-colons and you give it a value of "1;;3;4;5" you end up with five stored items "1":"":"3":"4":"5". It's only if you @Trim the field in its translation that you get the blank item removed and end up with four entries.
It appears this is no longer the case and that you always just get the four items. Has something changed or have I always been wrong?
What was I trying to do? Well, imagine I was trying to maintain a list of names, split in to three multi-value fields — FirstName, MiddleInitial and LastName. Imagine storing the names:
- Karen L Howlett
- Jake Howlett
- Teddy S Edwards
The three fields need to store "Karen":"Jake":"Teddy", "L":"":"S" and "Howlett":"Howlett":"Edwards". If the MiddleInitial field doesn't store the blank entry for my name then it all goes to cock. Names are wrong and @For loops throw errors.
As a fix I used normal text fields and separated values using my own method. I'd be interested to know why I had to though.
Skip to the 
You can subscribe to an individual
Hi Jake
Just a quick test with this shows that if you put a space in as an entry it doesn't trim it so maybe try putting in a translation formula to change a blank into a space and then trim it when you concatenate them so there's not an extra space in the middle. Not the best way but i can't see another way just now.
Hi Lee. Even when I put a space in it trims that as well. What version are you using?
6.51
Jake,
Blank/null entries have always been removed within domino multivalue arrays. The classic test does not require programming either. Just do to the server configuration document. in the field where tou can block domain/ip addresses for inbound SMTP. enter something with a double semicolono or just do an extra carriage return. you will notice it removes null entries.
hope this helps
Definitely always Patrick? I'm sure I remember a time when they weren't. I only remember this as at the time I *wanted* them to be removed and thought that an annoyance.
Is there no way to include blank entries then?
A quick check in 4.6 gave the same result. So, as far as my Notes experience goes, this has always been the normal behaviour. :-)
But don't wory: Just one week ago I found out that the underscore IS a legal character to start a field name with, when I always thought it wasn't. Things like this keep happening, but not only in Notes, I assume.
This goes back as long as I can remember - Can't remember if this happened in v3 but for years I have been adding null values as "~" or "#" instead of "" to keep those null values - especially when there are several multi value fields forming a "table" of corresponding values.
It's always trimmed them automatically. That's why we had to put "." or something for the field values in a "dynamic" table.
I'm with Jake-- I thought the default was *not* to trim the blanks from a list...
Thanks Seth. I thought I was going bonkers ;o)
Whether or not it ever was the way you and I believe, I'm adamant that's the way it *should* be in a world of common sense.
When @trim is used I know this was true in R5. In R6/R6.5/R7 I did @trim within you example and it does show this result. It is possible to have blank lines or null multivales, but that is due to backend (non gui method) to create document(s). I've seen this get trim via the notes client though as well. So I would like see an example app and a specific release / build, Was this behavior client side or web side?
I've actually seen (or think I have) a change in how @Trim works: used to be I could use it to remove either null entries from a list or redundant spaces from a single value... got burned the other day when it suddenly did both, removing redundant spaces from each value in a list where I wanted to remove null list members but keep redundant spaces (don't ask).
Multivalue fields in Notes have behaved like this for as long as I can remember, which is R4 for me.
This has only effected me in when I wanted to show a table where null entries are present. When this was the case I had two options to preserve the null options in a multivalue field.
1. The multivalue field that needs to store the null values is not on form. For example if the field is constructed back end and saved to the note then the null value is preserved. The key to this working is to remember that the in memory and backend documents store different values and you can copy the value of the in memory field to another field on the backend document not saving the original field.
2. Translating the null values to another character so that Notes would register it a valid entry in the list and preserve the order.
I know both these methods are hacks, but we are talking about Lotus Notes.
Regards,
Anthony
Jake, I've been developing in Notes since the R3 days and I'm 100% certain that @Trim has always removed blank entries from the list.
Hm. Let me try...
"Microsoft;Sun" ".NET;Java"
Now if I make .NET a null... hm. Everything still looks the same.
;-)
Too vague?
Wait a sec everybody. Yeah, @Trim will trim out the blanks. It's always been that way, and Jake knows that. Problem is, the nulls are getting trimmed without using @Trim.
Well, I think the distinction is that computed fields and editable fields do things kinda differently. In a computed field, the nulls will remain (unless @Trim is used). In an editable field, the nulls are automatically trimmed (apparently it's assumed that consecutive separators equate to user input error or something)...
So, what to do...at a high level, here's one approach:
If all the values are on a single document, create a table or grid mechanism. Computed fields for First, Middle, and Last names. An "Add" button to bring up a dialog box or something to add a "row". A "Delete" button to bring up a dialog in which the row to delete can be selected. An edit button (first dialog is to select the row, second dialog to actually edit that row).
That removes the auto-trim behavior of editable fields from your form. The null values will remain in the computed fields.
Hope that helps.
Rod
Side note: "Trim" in LotusScript is the one that removes only whitespace. They added "FullTrim" to duplicate the behavior of @Trim.
To be pedantic, I shouldn't have used the term "nulls"... Empty, or Blank would have been more appropriate. Still, you get the idea.
Rod
Rod - you're right. I misread the post, I thought Jake was questioning the @Trim functionality.
Uff, thank you Rod, I started to be afraid about one of our application, where we use space for empty values and it's working - because it is computed fields.
its really good can u send me this dattabase