I find the behavior of the numeric text field a bit... funky. Especially when it doesn't have a value.
Right now, the default empty value is nothing. Which is interpreted as an empty string.
This makes a 0 appear in the field instead of the placeholder.
The only way I found to make the placeholder appear is to set
null, which makes this appear:
I, and I suspect many people around here, don't like red triangles.
And even if you ignore this error and use null as a default, if a user enters a value then deletes it, it goes to an empty string.
The whole thing makes doing calculations based on several numeric entry fields quite an exhausting exercise:
Before values are entered, you're dealing with nulls (if you want the placeholder), which is fine, but then you also have to handle strings in case the users delete their input. And the placeholder never comes back, a 0 is displayed - which makes the users think they actually have a 0 there.
I guess the tl;dr is this: please make the empty value of the numeric field a null.
Now I understand this would break things for projects handling empty strings, so I really have no idea what can be done, but frankly, I needed to rant about this.
i have this problem as well, the numericEntry show 0 value instead of place holder.. any solution yet ?
The only way is to monitor the
value property and check for empty strings, in which case you need to set it to
The whole thing is a pain in the ass, hence the improvement request.
A workaround that I can think of is using a property change script on the value property to change it to a null value whenever theres an empty string.
Before I begin, I want to be clear that I agree with you and that I raised this very issue during the Alpha phase of Perspective. It's been so long now that I can't recall the reasoning for why we chose the direction we did.
Unfortunately, I believe we're more or less "stuck" with the current behavior because there's an excellent chance that users have implemented project behaviors around what we have documented as this expected behavior. If we were to change the default value for a Numeric Entry Field (NEF) to be
null, there are two approaches we would conceivably follow:
- ALL NEF (old and new) components now load up with
null as their default value if no value is supplied/stored in configs. This breaks existing project logic which expects empty strings. The end result is users now reporting broken project logic to support because that project logic was based on documented behaviors.
- Only NEWLY PLACED NEF components default to
null when there is no configured/stored value. This is less likely to break existing project logic, but now you have one component with two different behaviors; old NEFs display
0, and new NEFs display nothing. If a View has both, does a
0 truly convey
I suppose it could be new component ("alternate numeric field" or similar) with the default null. Are there any other outstanding issues with numeric fields that cannot be fixed for backward compatibility reasons?
2b. add a property to the NEF, maybe a boolean, that allows switching from one behavior to the other, so that we can 'convert' old style NEFs to the new style by just checking a box ?
This doesn't fix the 0/null inconsistency, but it makes switching to the new behavior quite easy, and leaves the task of making things coherent to the integrator - which is part of his job anyway.
Or... We could just update the schema warning to allow for
That would actually be a good start, but it's a cosmetic fix. It doesn't help with the value resetting to a blank string when the user removes the number, which wouldn't be that bad if it didn't make the field display 0...
How about making the empty string not display 0, but the placeholder instead ?
That shouldn't break anything.
I'll run that by the relevant internal parties.
It turns out we already have an open ticket to improve the placeholder usage around empty strings, so these two tickets in tandem should alleviate all of your concerns.
That's great, thanks a lot !