Hi Kevin,
So I assume you are refering to a "Calculated Value" control on the form? If so, you do have the Save as data type set to string? I would think so. Sounds very strange.
Cheers,
Mark
I came across this in the past too.
I reported it to support considering it's a bug but was moreless told it's a 'feature'...
basically, once a formula in calculated control value returns a value that is convertable to a numeric, it's treated as number regardless of what you set as datatype.
I was given workaround to encapsulate formula to a function that returns string, eg. tolower()
Mark,
That is how we set it up but that will only save the data you are doing to your column as a string which it does. But before it ever saves we have it doing a compare to another string but the calculation field is making the string of number into a Numeric value since its all numbers in the string.
Marian,
Did the tolower() work because I've done the toupper() and it didn't work it still calculated and read the string as a numeric value.
I've also found a couple other post and sounds like there was a fix to this back about a year ago but it messed up with a bunch of other thing so they took it out and where going to keep working on it. And last post i saw was there was to be a fix on it back in Jan. but haven't seen anything on it.
for me it worked.
but till I got that workaround from support I find myself another one how to force it to return string, in your case it would be something like: Userprofilelookup("CurrentUser", "ID") +"x"
let's try it whether it will work for you.
I dealt with support reg. that 1 month ago and was told following when I asked if they plan to fix it.
The function that you have requested is still not part of our feature set |
Marian,
Thanks for your quick replies, ive tried both toLower() and toUpper() with no luck. Also tried the UserProfilelookup("currentuser", "id") + " ".
So we have a List Voters that will house IDs for the people that can vote on the poll, then the form checks if the user that is logged is in that list. So adding something to the end or front wont work to much. Its just fun that its taking a string variable to start with then it just goes oh cause no letters in it, Im going to make it a numeric value.
Thank you again for the help and ideas you are given.
adding a space will not help, since it still doesn't prevent to convert it to numeric. just for the case try it with some non numeric character.
for me it as well caused lot of troubles since I had to strip that postfix off at every place I used the formula. but haven't found anything better.
Was looking behind the scenes in the code and Nintex has it built in that the if the calculation field recognizes a bunch of numbers to automatically change it to a numeric value. Have read some post that at one time there was a fixes for that but that was un-patched and something was to be released in Jan. to fix this issue. Has there been any updates on that?
Have started to test this with other controls and even a form variable. Even if I set Type to String, Nintex is automatically converting a string of numbers into a numeric value versus keeping it as a string. Why is this and is there a fix for this? Is there a workaround to keep a string of numbers from becoming a numeric value?
Workaround that i have come up with for this issue.
Calculation Control - add a +"x" onto your number that shouldn't be
then where you need just the number substring out the variable
So in my case it was
Calculation Control (ID) - userProfleLookup(CurrentUser, "ID")+ "x"
Then in our rules for doing compares we then substring(ID, 0, (Length)) length being how far down the string you wanted to bring out.
Now everything is working like it should. Also seems the Nintex Development team is still working on a fix for this issue but till then will have to use a workaround.
Kevin Kittinger, I'm a bit lost in your explanation. could you post some example or could you explain it in more details.
is that something else from what I have suggested?
Marian Hatala It just builds on what you suggested. For my particular situation where we then had to sub-string out the x to do the comparing of our calculation field to our list of IDs. I meant to mark yours correct as a solution but was writing up mine and was in a bit of hurry sorry on that.
