Probable display bug in number fields

Anvil Q&A
1

What I’m trying to do:
Display a whole number (e.g., an Issue Age) for entry, as a whole number. Many of our inputs are whole numbers, with no fractional part, by definition. They are stored in the database, in SimpleObjects, as integers.

What I’ve tried and what’s not working:
They now display as this: image

This value is stored as an integer, but is now displaying with a decimal point and fractional digit. Earlier this week, it was displaying as just “60”. As it should.

In fact, virtually all of our integer-valued fields now show a fractional part.

I could not find any new setting in the TextBox component that would explain this. Is there some new global setting?

Edit: Browsers tested so far:
FireFox: 60.0
Edge: 60.0
Chrome: 60.0
Safari: 60.0

Edit 2: I suspect there should be some “hint” we can give, when the value is supposed to always be a whole number, so that it can be displayed appropriately.

2

I could not reproduce this.

I created a new blank app, a data table, created a table, added a single column of type SimpleObject to the table, typed the number 1 in the first row. I then added a Text Box and a Label to the default form, named them, and then in the form code retrieved the value from the data table and assigned it to the text of both the Text Box and the Label. In both cases, the value displayed correctly as 1.

Unless I misunderstood how you’re storing values in your data table?

Ken

1 Like
3

This won’t address the core issue, but here’s one way you can apply formatting:

4

Hi @p.colbert,

That sounds very strange. I’ve created this demo app to investigate but the numbers are displaying correctly for me:
https://anvil.works/build#clone:7YIPBELTTMSAAPDY=KDNJR2YV2KKHJC5GQRKNV3VL

Things I’ve tried to recreate the bug:

  • Integers and floats in both Number and simple object fields
  • TextBox components and Labels
  • Placing both TextBoxes and Labels in a Repeating panel
  • Tried different Types in the TextBox properties

Could you provide a clone link and/or some further steps to reproduce the problem?

1 Like
5

I may have found the problem. And it’s probably my problem.

I wrap the TextBox in a custom component, so that I can explicitly set MIN and MAX values. I use the same component for both entry of both floats and ints.

As a safety net, just in case the SimpleObject had supplied the value as a non-number (e.g., due to a prior data conversion or format conversion), I have been casting the value to the more general form, float, just before entry. (No point in alarming the end-user for such a data problem; not when it has such an obvious fix.)

Until a few days ago, that was fine. A whole number, even if it was a float, would display with no decimal point or fraction. That seems to be what has changed.

Cast your integer values to float, in the Data Binding expression, and you’ll see the effect. “.0” will be appended to the value on display.

Whether this is universally desirable, may be a matter for discussion.

A float with no fraction will still save to SimpleObject as an integer (no fraction), so the difference in data type wasn’t visible in the database.

In case this bites someone else, it may be useful to add a flag to Number fields, to explicitly say “integer only”. Default: False.

In the meantime, since there now is a difference, it may help to document the difference.

For my own App, I’ll discuss, with my colleagues, what behavior we want to present to users, and alter my Custom Component accordingly. (Some of my fields, e.g., a person’s age, are clearly integer-only. For others, it’s much less clear.) This may mean adding an “integer only” flag, or hooks for data-conversion functions, where it makes sense.

6

If you’ll permit me a bit of presumptuousness, there has -got- to be a simpler way :wink:

If you need that much structure and conditional logic and casting and database flags indicating the type just to display a whole number… well, it just feels very brittle and likely to cause you more headaches in the future.

Might be an opportunity to refactor?

EDIT: And as many programmers have echoed both here and across space and time: stay away from floats unless you reeeeeally need them :wink: Two integers are better than a single float in some/many cases.

Cheers,
Ken

7

Yeah. Time to step back and look at the data-design. Some values are, by definition, integer-only. Some are not. That distinction has to be made somewhere, or you’re going to be displaying and entering invalid values – like an age of 60.8333333… years.

For integer-only values, it makes real sense to display them in an integer-only data-entry field, one that forces the min, max, input, and result into an int. As they should be.

To do that, I would re-factor what is currently an overly-general (int-and-float) Custom Component, into two distinct Components, one for ints, and one for floats. This makes the distinction far more explicit, and simplifies the code for each Component, but also helps enforce the data model where it should be enforced: at time-of-entry.

For the Anvil-standard component, well, I’ll leave that up to discussion. We already distinguish between subtypes “email”, “phone number”, “url” and “number”. We do that for mobile uses, so that the browser will pick the best pop-up keyboard. If the browsers start supporting a distinct “integer” subtype, that would almost certainly be added. If not, then there would still be value in supporting it, within Anvil, but perhaps not as much value.

1 Like