I have an issue with the calculated value control whereby it will parse the calculation result as an integer despite my explicit declaration that it to "save as data type" as a string. The reason this is a problem is because I want to use the value of the calculated field later in the form to filter another drop down control.
When I configure my calculated value control with the following formula to retrieve the first 3 chars of my drop down (after parsing the lookup and getting the value)
I correct am returned a value of "02:"
However if I change the formula to return just the first 2 chars of the same drop down value
I am presented with a calculated value control value of "2". It's as though, despite as above I'm saying store the value as a string (I want to maintain the prefix of 0 if it's there) it is parsing it as an int.
Does anyone know a workaround for this?
You can use a regular expression with the replace function:
replace(LambPlot ,":(.*?)*" ,"" )
In this case:
If LambPlot is 02: [ Ewes(3)blablabl
the regular expression will match : [ Ewes(3)blablabl
and will be replaced with empty
I've also found this to be an issue sometimes. If it's a "number" string, it seems to be converted to a number regardless of what you do. I did find a little work around by using "" + yourField instead of just your field. (the concatenation of an empty string "" plus your field may fool it
Thanks for the hints guys but Fernando Hunth the replace() with a regex also exhibits the behaviour. This is because the value string is passed to the faulty control regardless of how it was generated. This also occurs if I just set the formula of the calculated control to be 02, the 0 gets stripped off.
Jan Potyka , good hint but unfortunately it didn't work in this case
Hi Stu, This is a known issue. It was fixed in a previous build but the fix broke other functionality of the control so the fix was removed. Nintex Development teams are still working on this issue. There is currently no workaround.
I'm experiencing this problem as well and it is very annoying. My temporary 'fix' is to use an uppercase letter 'O' as a stand-in for '0' for those cases where it is used only for display (with the right font it is hard to tell the difference). Of course, this won't work when this field is needed to lookup values in another.