Select to view content in your preferred language

Calculation Mode Auto not working as expected after 3.18.142/5 update

1451
4
08-29-2023 07:19 AM
Mondi_GIS
Frequent Contributor

Good day, 

We have encountered a bug in our Survey123 forms which are really critical for capturing incidents. The process goes that the Loss is calculated by default as 100% of the Affected (either trees/hectares etc) and then the calculation mode is set to auto so that if we manually adjust it, it shouldn’t over write but what is happening is that it is recalculating that value on submission and overwriting the user input. Essentially the auto is behaving more like always mode and constantly recalculating even after user input. This seems to be a bug in all the latest versions (3.18.142 and 3.18.145) but works as expected on the older versions installed manually on windows eg 3.15.145

4 Replies
ZacharySutherby
Esri Regular Contributor

Hello @Mondi_GIS

Would you be able to pass along the XLSForm experiencing the issue for testing on our end? If you set the calculationMode to whenEmpty does that resolve the behavior? 

Thank you,
Zach
0 Kudos
Mondi_GIS
Frequent Contributor

Hi Zach, 

The whenEmpty mode doesn't work for our tool because it needs to recalculate when I change the method of defining loss (Hectares/percent/trees). I would need to strip down the xlsform significantly before I could share it because of a lot of validation and pull data functions on private data. Can I perhaps email it?

0 Kudos
Mondi_GIS
Frequent Contributor

I have managed to strip out the bulk of our form and the lookups and just have the calculation that is not behaving correctly. So far the feedback from ESRI is that it is an "expected behaviour" which I do not agree with. 

On further investigation, the calculation mode behaves as "expected" when there is no appearance applied to the numeric field. When I apply the numbers or calculator appearance the calculation mode behaves as though it is set to Always instead of Auto. Because of our locale settings, we have to have the numbers appearance in use for anything with decimals. 

 

The field of concern that is recalculating erroneously is the "lost"field. 

0 Kudos
Mondi_GIS
Frequent Contributor

Any further insights from anyone? @ZacharySutherby?   

0 Kudos