Input mask doesn't work with readonly set to "yes"

668
6
01-05-2023 02:21 PM
LMedeirosUI
Occasional Contributor

Hello - I was wondering if there was any reason why an input mask does not apply for a calculated text question that is set to readonly?

We are trying to use keyboard wedge software to pass PIT tag info into S123. Sometimes the info passed on isn't formatted properly (has more info than needed), so we have a readonly field that grabs the last 14 characters (the actual PIT tag).

This is our first year using S123, but many techs experienced issues with transient lower case characters in the PIT tags. This causes the pulldata functions to not work as it's case sensitive. While we're fairly confident it's because the techs left the caps lock key on, we figured we would try to force the entry to be upper case only and solve the issue entirely.

Turned out to not be so simple. Because the pull data function happens in real-time, we cannot use Excel to change the case of the characters after the data is submitted and I couldn't get the UPPER function to work in the XLSForm. The input mask of >xxxxxxxxxxxxxx should work, but it (apparently) can't be applied to readonly questions and if we don't apply it to the "clipped" field then the length of the input from the PIT tag reader could vary depending on the keyboard wedge software and settings being used.

So, other than using a large amount of x's in the input mask field, is there another elegant/simple way of doing this? I have a working javascript, but it requires the addition of a calculated field and while that's doable I'd rather avoid it.

I have the form attached with the two workable options (javascript and lots of x's, respectively) in the PITtag questions (rows 28-32). I've also attached the javascript. Hoping I missed something obvious.

Thanks for any input! Lea

Tags (2)
0 Kudos
6 Replies
DougBrowning
MVP Esteemed Contributor

I think input mask will only work while you are typing.  Have you looked at regex instead.  Not sure it will work either but worth a shot.   https://doc.arcgis.com/en/survey123/desktop/create-surveys/xlsformformulas.htm#ESRI_SECTION2_BED1A39... 

But I have found that being read only somethings do not ever run since it assumes the data cannot change.  Maybe setting the new calculation to always would help if the above does not.

hope that does it

0 Kudos
LMedeirosUI
Occasional Contributor

@DougBrowning RegEx isn't a good option in our situation because all it does is alert the user that the input isn't in the correct format. As the input is being imported from the PIT tag reader (if you aren't familiar with what that is, it's an RFID reader), they aren't the ones actually typing it in. This is to prevent human-generated errors as the PIT tag codes are a 14 character alphanumeric string that are often messed up when entered manually (speaking from experience). Regex would require them to enter it manually if the lower case thing was happening and we don't want that.

Magisian also suggested trying a different calculationMode, but nothing seems to change (even when set to manual). Any ideas why that could be?

0 Kudos
DougBrowning
MVP Esteemed Contributor

I mean put the regex in the calculation field not the constraint.  You also may be able to have 2 fields where the first is the raw input and the second uses regex to convert it.  I do not use regex much but it may work for that.

ChristopherCounsell
MVP Regular Contributor
Regex is a constraint, like an input mask, I don't believe it calculates
values. They don't actually want to mask input values here as they seem to
have accepted the values will be input incorrectly by the users/codes.

The lack of available 'upper' functions in the xlsform is addressed
elsewhere and the suggestion is to use the external JavaScript function.
This appears to be where the user reached.

The OP is having issues with the calculations firing in the correct order.
I.e. get row one value, then apply JavaScript function on this value in row
two to convert to upper case. I believe the solution may be to set the
calculation mode to manual and have the user hit the calculate button for
the pulldata JavaScript function so that it fires after the value has been
input.
0 Kudos
ChristopherCounsell
MVP Regular Contributor

An input mask in the Survey123 field app requests users to use the specific pattern. If the question does not meet these requirements, the users can still submit a survey. If the question is read only, there is no point to having an input mask?

https://doc.arcgis.com/en/survey123/desktop/create-surveys/esricustomcolumns.htm#ESRI_SECTION1_2D9AA...

You could make it a constraint instead but then it can't be corrected as it's read only.

The simple solution is to pull the data into a row and then apply an expression to calculate the data (truncate + Upper). Unfortunately this doesn't work for you as Upper isn't supported within XLSForms.

So you need to apply the Upper expression using the JavaScript. But this isn't working because it's real time? What do you mean? I would take a look at this - maybe try use calculationMode = manual so the user has to generate the value when it's required?

https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-calculation-modes/...

LMedeirosUI
Occasional Contributor

@ChristopherCounsell Regarding readonly not being input my answer is yes and no. The form still allows for calculations and the like, so the field is being populated from somewhere. In the case of my form, it is truncating the input from the field that was populated by the PIT tag reader/keyboard wedge. Yes, in most cases, it makes sense to put the input mask on that field, but I don't see why input masks don't work on readonly fields if there is a calculation being performed.

The javascript works just fine; I just don't like having to add a calculated field to my form.

As mentioned in my response to Doug, using regex/a constraint makes things worse as many PIT tag readers are set to not read duplicate tags. So, if there's an issue, techs have to go back and manually enter the tag and that has definitely generated more errors in the past.

I attempted the calculationMode suggestion, but it still does it automatically (even if I remove the inputMask). Any clue why? Does the form have to be a certain style?

0 Kudos