select_one - no integer values

821
4
Jump to solution
06-16-2019 02:31 PM
Nicole_Ueberschär
Esri Regular Contributor

Hello everyone, 

I have a form with two select_one fields where the value is an integer value with a text label. Even with saving the result from the select_one field as an integer value to a calculate field it will not be recognized as an integer value. When I try to calculate the average of the choices, it gives me just some weird numbers. It works though if I use an integer question to save the value from the select_one question as integer. But this looks awful (and stupid) in my form, I would rather hide this step if somehow possible. 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable

Hi Nicole,

This is the expected behaviour, as a select one question is actually a text field due to it being a choice list, even though you may use numbers as the choices, if you look in the feature layer and the esri field type, you will see it is always a string field. 

Therefore you can not apply mathematical equations to a string field the same as you can for integer and decimal. The ebst way around this is to use a hidden question type (so the user doesn't see it) and put the value on the select one into this hidden question by a simple calculation that references the select one, and then use the hidden question in your further calculations in other questions.

We have an enhancement in our backlog to honour the bind:type field for select one questions, as currently that does not work, which would allow setting it as "int" which would mean it is treated as an integer even though the values are stored as text. 

Phil.

View solution in original post

0 Kudos
4 Replies
by Anonymous User
Not applicable

Hi Nicole,

This is the expected behaviour, as a select one question is actually a text field due to it being a choice list, even though you may use numbers as the choices, if you look in the feature layer and the esri field type, you will see it is always a string field. 

Therefore you can not apply mathematical equations to a string field the same as you can for integer and decimal. The ebst way around this is to use a hidden question type (so the user doesn't see it) and put the value on the select one into this hidden question by a simple calculation that references the select one, and then use the hidden question in your further calculations in other questions.

We have an enhancement in our backlog to honour the bind:type field for select one questions, as currently that does not work, which would allow setting it as "int" which would mean it is treated as an integer even though the values are stored as text. 

Phil.

0 Kudos
Nicole_Ueberschär
Esri Regular Contributor

Hi Philip, 

Thanks for your quick response. I was guessing already that the integer values are not supported at the moment for select_one fields...

Can you maybe point me to an explanation of the difference between the bind::type and the bind::esri:fieldType columns? When I used the bind::esri:fieldType to make the hidden field an integer value it was ignored and still stored as a string. Only when I selected int in the bind::type column it was actually overwriting the default string setting. 

Do you know anything about when we can expect the next full release? (not Beta) Ismael Chivite‌? James Tedrick‌?

0 Kudos
by Anonymous User
Not applicable

Hi Nicole,

The bind::esri:fieldType column is a custom xlsform column that Esri uses to set the field type in the feature layer when the survey is published and feature layer created, similar the bind::esri:fieldAlias and bind::esri:fieldLength, these are also used to manage the feature layer field options.

The bind::type column however is a xlsform standard column, and is used to manage the field type within the app, part of the xlsform specification. This is the correct column to use if you want calculations in the app to honour the field as an integer at the time of running the form.

If you then want the values to be stored as integer in a field that is not normally not an integer, you can set the bind::esri:fieldType when publishing so that the corresponding field is created as an integer too.

As for the 3.5 release (next full release), it will be available before the end of June, not far away now!

Phil.

Nicole_Ueberschär
Esri Regular Contributor

Thanks Phil!