Tapping on a note field changes its type

[DougBrowning2]

Weird one for you.  I have a form with a Note field that subtracts two number fields.  It is bound to a int.  It is later used in a sum() from a repeat like sum(${Cat1C}).  On a tablet but it does it on connect also.

If a user puts two numbers in and hits next on the repeat it all works great.  So say you have a 25 in one repeat then a 35 you get 60.  But if the user "taps" on the note field then the final sum changes to a concatenate and you get 2535.  You cannot tap into and change the field but since it still looks like txt box you can tap in that area.  It does make the calc show but then it is somehow a string.  If I hit the check mark on the google keyboard, make sure to not tap anywhere else and advance the repeat it also works fine.  Only the tap breaks it all.  We can get this to happen on demand.  

For now we have to tell people not to tap on it.  Even though they really want to see that number.

Any ideas?  Must be a bug?

Thanks

[JamesTedrick]

Hi Douglas,

Note, hidden and calculate fields all have a default type of string.  As with calculate questions, if you want to use it in a formula later, set the bind::type column to a numeric type (int or decimal).

[DougBrowning2]

That's the thing James it IS bound to integer.  I had to do that to get it to work.  This is different.  Again it works like it should except when tapping on the field.  If you do not tap it works.  Try it once you will see it happen.

I can send the form if you like.

[DougBrowning2]

Could it be that it should be int instead of integer?  It is integer in the Esri bind so figured it was the same?  It did make a difference when I added it though.

[JamesTedrick]

for bind:type, the value to use is int

[DougBrowning2]

Well changing from integer to int worked!  Weird that it worked sometimes.  Why is the esri bind integer and just bind is int.  Gotta admit that is rather confusing.  Should really be consistent, esp if its not documented.

We launch Monday so was a bit of a panic.

Thanks

[JamesTedrick]

Hi Douglas,

The naming is an issue in the XLSForms specification vs. XForms specification - XLSForm (which is used as a shortcut for XForm) specified integer to be user-friendly; XForms (which we're accessing through that column as a manual override) uses int .

[JamesTedrick]

Hi Douglas,

I've attempted to replicate the behavior you are describing but am not seeing it with v. 2.7 - can you see if the attached file replicates the behavior on your end?  Can you share the form that is experiencing the problem?