Possible Bug: Number("") is not working as expected

NUMBER("") expression is not working anymore as expected and as described in the linked doc.


1 18 540
18 REPLIES 18

Yes it shows the zero with the gray color, but when you save the record, I believe it doesnโ€™t show or save any valueโ€ฆ not even the zero.

@Aleksi,
Earlier the behavior was not like that. It was showing just a blank value, not even a greyed out zero like this. Besides, the doc is comletely inline with the previous behavior but now it also contradicts as well provided that behavior had been changed.

Why would you like to use the initial value with the NUMBER("")? The result is the same with or without it.

Simply I donโ€™t want a value to be appearing as zero, even if itโ€™s a ghost value indicating that the field is a number field or requires a numeric value.

Earlier; if you leave the initial value blank, the field was already appearing like this in the form view. Then upon some requests, NUMBER("") expression brought to use. And there are several post I remember that both you and I and many others have replied with use of NUMBER("") expression in the initial value to whom was asking how to eliminate that zero initial value.

So as to say, Iโ€™m not pretty much interested with the result. Iโ€™m interested with the UI.

I too prefer a field like this to remain blank. In some instances, a 0 in a field could actually mean something vs. a blank.

Absolutely! The UI should not indicate a specific value will be assumed when it wonโ€™t be.

We also prefer the ability to set the initial display value of a Number field to a blank / empty value. We are still not finding this to be an option.

We actually received complains from app users, claiming the placeholder for number type field is currently showing 0 which looks like initial value or acutal 0 value is already placed, and not really assinting user what to do with such a field.
At a glance, it looks like 0 was initally placed upon opening new form.
Better not to show this, or better to give us, app creator to place our own placeholder for each of entry field on the form view.

This is not an ideal workaround, we twisted โ€œdescriptionโ€ setting with IF expression to guide app user to place number for such a fields until we get the permanent solutions.

3X_3_3_336df1eeebe06c5cf384ffb7604461498ee1c337.gif

@Takuya_Miyai

@Arthur_Rallu

Not collecting much of interest, but current appsheet UIs for input is not really helping app users.
Not able to apply prefix/suffix, and no control over the placeholder neither.

Matrial UI is providing property to control the placefolder, why dont we take it for Appsheet to give us more hands to control over?

@Arthur_Rallu

@Takuya_Miyai

still no solution for this? I need the possibility that a field remains blank, not 0

I assume you mean a Number type field.  If you assign "NUMBER("")", it should result in an empty value being assigned to the column rather than zero.

Let's not forget DECIMAL("") has the same problem and the more decimals you allow it becomes visually more uglier

@luisandres @Kabuliรฑo 

I don't understand the issue you two are having with NUMBER("") and DECIMAL("").  I just ran a quick test and both of these are blanking out the numeric values as expected (see images below).  Please describe your individual issues AND app implementations so we can best help you figure out what is wrong.

Data sheet showing assigned numbers

Screenshot 2022-11-15 at 7.51.14 AM.png

App table showing numbers

Screenshot 2022-11-15 at 7.49.58 AM.png

Top row columns reset using NUMBER("") and DECIMAL("") functions

I setup a button that when tapped set a column to TRUE activating the "Rest on edit".  This fires off the "Initial Value" property executing the expression which sets the columns to "blank".

Screenshot 2022-11-15 at 8.02.50 AM.png

Data Sheet columns AFTER the updates - columns are empty

Screenshot 2022-11-15 at 7.52.20 AM.png

 

For me it is not a very big problem, rather just an aesthetic problem.
I have a detail view with editable fields of type Decimal, its initial value is Decimal("").
I would think that Decimal("") should be represented in the view as a white space, since if I wanted 0.000 to appear I would use 0.000 as the initial value. The same thing happens with views of the Form type.

Maybe I'm just misunderstanding the documentation  
https://support.google.com/appsheet/answer/10107887?hl=en&ref_topic=10104782

 

That value shown in an "uassigned" Number or Decimal field is NOT an actual column value.  It is more like a "watermark" - an example value - shown only when the column is empty.  It is slightly greyed out - maybe there should be even more contrast?   If you save the row without filling in those fields, the column will be empty.

There is no way to hide that "watermark" value - possibly it should be optional?

In my opinion it should be optional.
I suppose the purpose is to help the user understand the type of data that can be entered, but in the case of views for cell phones and tablets I don't see it as necessary because the keyboard itself determines the type of data that can be entered.

If the field is used as input to make a calculation in another column, the user might think that those zeros will be used to make that calculation.


@Kabuliรฑo wrote:

If the field is used as input to make a calculation in another column, the user might think that those zeros will be used to make that calculation.


Except that as an app creator, you should validate that a valid value has been entered when its required.

Top Labels in this Space