Hi all
I am following Appian standard in using a text field on a form with which to populate a decimal field in my rule input.
Appian standard behavior for a decimal field is that if a comma symbol is used to indicate a decimal place, the symbol is automatically removed and the value is then displayed with no separation.
Example:
The user enters 650,52
On refresh, the comma disappears and the value saved in the rule input is now 65052
If one uses the period symbol, the value is displayed correctly, thus 650.52, and the value is saved correctly into the rule input
We cannot assume that the target group of users will understand the distinction between the symbols, so we need to put in some sort of validation in order to avoid the issue.
I have tried using the cleanwith() function, but am unable to make it work.
I would like to be able to do one of the following (in order of preference):
Any help will be greatly appreciated!
Discussion posts and replies are publicly visible
Something along these lines? Does the job but probably could use some tinkering.
a!textField( label: "Your Decimal", saveInto: a!save(target: ri!decimal, value: todecimal(replace(save!value,find(",",save!value),1,"."))), value: ri!decimal, )
Out of interest, what Appian standard of using a text field instead of a decimal field are you referring to?
Out of curisoity, have you verified this behavior with a user account whose Locale is set to one that would use the "comma separated decimal" convention? Because I wonder whether you're trying to re-invent the wheel here.
Hi, Marcel
HALLELUJAH!
Thank you very much, that does the job.
The Appian standard I am referring to comes from the usage considerations section on this page:
https://docs.appian.com/suite/help/22.1/Floating_Point_Component.html
which refers to using a text field to apply special formatting such as currency.
Regards
Stephen
Thanks, Mike
Unfortunately it's not that simple in my case - I am in South Africa and there is a lot of confusion around the correct separator use - see below from limn.co.za:
"Technically speaking, the official format for numbers in South Africa is spaces for the thousands separator and a comma for the decimal mark. The American variation that we had become used to is commas for the thousands separator and a full stop for the decimal point."
confusion reigns as a result....
On what Marcel suggested, if you try to insert a number having 2 commas or having a comma and a dot as separators then it's not working properly. So that needs some improvements on what number formats can be accepted. Also, because the component is a textField, it can accept letters also and not only numbers. So you have to use the cleanwith() function to allow only numbers, periods, and comma characters to be inserted.
Also, an OOT, are you suggesting your answer as a correct answer to your own question? That's bizarre man LOL
Understood. I think this would (also) be a perfect use case for things like the Instruction and/or Placeholder text.
Thanks Mike, I would have used the placeholder or instructions option but in many cases our target user group has English as a third, fourth or fifth language.
AFAIK the "proper" solution for this is a strong internationalization setup, providing alternative language versions of the same forms / field names / text values on existing forms, though I must admit I haven't yet had the chance to design or maintain a system with a robust multi-language setup like this so I'm not very versed in what all needs to go into it to do an initial setup.
I would look at that but this country has eleven official languages :-)
I don't suggest you try to cover ALL possible languages - but having more than one option (like by cherrypicking the one or two most common alternatives) would still possibly be better than no options. And once you've figured out how to flexibly implement a small number of alternatives, it'll likely get a lot easier to gradually implement more options, if and when the need arises.