Calculated Value Expressions Getting Confused When Field Names Have Common Root

[JustinReynolds]

I'm having issues with field calculated on Android if they are in a certain field order.

Android Samsung Galaxy S10+, Field maps 21.1.x and 22.2.0.  Not a problem on iOS that I have seen.

This took a bit to track down, but I think I found the cause of the issue.

Say I have a field named "service_date" that has a form calculation and another field called "service_date_override".  These field names have a common root... "service_date".  Another example is a field named "stationing" (a calculated value) and another field named "stationing_offset" which have a common root name of "stationing".  On Android if service_date appears after service_date_override in the form order, the valueExpression does not execute.  In fact all calculations below seem to not calculate.  Below you will see some examples of what is happening.


The order of fields as intended.  The valueExpression for the service_date field never fires (no animation either).

Original Field Order

Switching the field order in the form, the valueExpression for the service_date field fires as expected, albeit not in the order I want or that is logical for the user given that I have an override switch control editability of the service_date field.

Reversed Field Order

Finally, to confirm that this is the issue I added another date field between the to fields that have a common field name root that had a different name all together.  The valueExpression for the new field fires as expected, but again the service_date field does not calculate.

[Woodpecker]

Thanks for sharing Justin. A very similar thing is happening to us but in reverse. Works on Android, doesn't pull the calculations through on iOS. 

[JustinReynolds · Accepted solution]

As a follow-up, I posted this in early adopters as well.  Esri was able to reproduce the issue; I didn't get a bug number, but it is on their radar.  

[MiltonSolano]

Folks,

Tested on Android and the problem is there: if the calculated fields have names with a common root (in my case COD) then the calculations are ignored. I was breaking my head wondering why my arcade code wasn't working until I found this post and changed the field name to BAND_CODES instead of CODES_BAND to change the common root with other fields (CODES_TREES, CODES_DENDO).

Wao, I was going crazy trying to figure out what was happening. I hope the folks at FieldMaps fix this inconvenient bug.

Milton

[Anonymous User]

This should be fixed with the next release planned for next week.

[Woodpecker]

It is. I can confirm our issue that was happening on iOS is resolved now. 

Not sure if you guys have done anything to the performance of field calculations when entering data in map viewer, but it feels much more responsive!