Showing high integer numbers in a user friendly way (Was: Help on Input Mask)

[Nicole_Ueberschär]

Can someone help me on defining the input mask for an integer value that requires to end with three zeros?

EDIT: I guess I should define more precisely what I need to accomplish.

Our local currency is giving me a headache. Talking about prices you can have anything between 100 and 1,000,000 (or even more).  I want to ask for money spent on certain category of purchases but when the person enters 50000 you already have to look carefully at the number of zeros. I don't seem to get anywhere with the input mask - is there any other way to make it easier for the people to enter higher numbers? So I am looking for a way to display the entered number with a comma for thousands which I think would already help a lot. Like 100,000?

Using the numbers appearance type says "Applies to integer and decimal fields. Displays a custom keyboard." At the moment I see a general calculator type of keyboard using this appearance type. Since it says "Custom keyboard" I assume there is way to manipulate it?

[BrandonArmstrong]

Hi Nicole,

I don't think that you will be able to accomplish this with an input mask.

One option would be to have a following question which concatenates the value from your integer question with '000' in the calculation column.

It would look like concat(${previous_value}, '000').  If you just needed the actual value, you could have this as type hidden and set the bind::esri:fieldType to esriFieldTypeInteger.  This would be the value that you would want to store.

The initial entry, without the trailing 0's could be set to 'null' as you would presumably not need these.

So, the workflow might look like...

type	name	label	calculation	bind::esri:fieldType
integer	Question_1	Enter a value		null
hidden	conc_val	Concatenated Value	concat(${Question_1}, '000')	esriFieldTypeInteger

Let me know if you have questions.

Best,

Brandon

[Nicole_Ueberschär]

Thank you Brandon!

[Nicole_Ueberschär]

It is still not perfect but at least I got a bit closer:

if(${total_ex_calc}>=1000000, concat(substr(${total_ex_calc},0,string-length(${total_ex_calc})-6),",", substr(${total_ex_calc},string_length(${total_ex_calc})-6,string-length(${total_ex_calc})-3),",000"),if(${total_ex_calc}>=1000, concat(substr(${total_ex_calc},0,string-length(${total_ex_calc})-3),",000"),round(${total_ex_calc},-2)))

translates into if price > 1,000,000 then x,xxx,000, if price > 1,000 then x,000, else x00.

[Nicole_Ueberschär]

Now I am testing my survey on different devices and found some interesting (for me unexpected or at least unknown but probably as designed) behaviour: 

- When using the calculator the value is automatically put with commas as thousand separators. 

- On a bigger tablet (Samsung Galaxy 7), when using the number appearance but not using the number fields but the text keyboard, when pressing the "done" button, the numbers are put with commas as thousand separators.

- On the smaller tablet this does not work when using the number keyboard only. (On that tablet the number keyboard automatically is used with an integer field)

- When using the numbers appearance I get a comma sign to separate the thousands (I haven't realized this one before) and the number would be shown in red as long as the numbers behind the comma don't match. 

It would be nice if the numbers field would be "clever" enough to show the commas without putting them manually but it is already a relieve to see that I don't have to reproduce this by doing calculations for each field...