Null values in NumericUpDown

[timunie]

Hey Folks,

** PLEASE NOTE: This poll is closed now. Please do not Vote anymore **

I personally have a use case where 0 is a totally valid number. But I want to indicate in the UI, that there is no value set atm. Instead, I want to display some kind of watermark in my NumericUpDown. See #7725 for more details. The initial PR I made #7794 was not considered as good practise. Therefore I would like to ask you, what your personal preference would be.

It would be very nice if you vote in the below poll. If I missed an option, please comment.

[timunie]

Let me add one more thing. I noticed that NumericUpDown support Watermark. But as the value can never be null, one can't see the Watermark. It works if we make the Value be nullable. I think this is an indicator, that NumericUpDown should have some kind of empty state. If I got something wrong here, please explain it to me.

[robloo]

I fully support adding nullability. Here is a collection of my other comments.

[robloo]

Indicating the user hasn't made a selection is a perfectly valid and I'll challenge anyone to explain the public DateTime? SelectedDate property of WPF's DatePicker if they think this functionality isn't valid in core controls. It is fundamentally important in some applications to support null/empty values in input fields.

That said, I didnt prefer the way it was implemented in NumericUpDown and perhaps we need to just add a NaN defined some place for decimal. Or a Selected Value property along with Value.

I will be facing a similar issue soon with ColorPicker and think not supporting empty/no-user selection is ridiculous. If a core team member said that I challenge them to provide examples on why it isnt needed. Even TexBox supports this. It's fundamental.

[robloo]

There are many scenario where apps need to know if a user has/has-not made a selection. Zero in the case of a NumericUpDown is a valid number and is not enough to indicate no user-selection. This type of functionality is common in LOB apps where form field values are being entered. In fact every single control I am aware of has some way of keeping 'null/empty values for no user-selection.

When the NumberBox spec was widely discussed with Microsoft this was also a valid scenario. However double.NaN could be used to add this functionality. With the switch to decimal in Avalonia that was overlooked and it needs to be added back somehow.

There are two standardized ways of doing this:

1. Add a nullable SelectedValue property along with Value. This is the strategy used in DatePicker where the underlying type doesnt support empty/null.
2. In something like TextBox, null has historically been supported for this but string itself has an Empty state so can be used for this info as well. So these controls don't need a special case and additional property because the underlying type supports it.

#7725 (comment)

[robloo]

I think it would be better to follow conventions here. Have both a nullable and non-nullable property like DatePicker in WPF. Zero is an appropriate internal default but actually whatever is in the view model will be used. DefaultValue really does seem like an unnecessary complication.

For convention:

1. It's best not to have a nullable property. However, the concept of no-user-selection needs to be supported. Some types allow this because the type itself can be null or represent an empty value (string, double.NaN, etc.).
2. If there is no empty/null value provided by the data type, then use a nullable property like what you have. However, I think both a Nullable/Non-Nullable property should be supported. This would be like the CalendarDatePicker/DatePicker controls.

This means I wouldn't make it a breaking change to have the Value properties nullable. instead I would only add one new property for SelectedValue and track internally when the user has provided input. If no user-input, return null here. Otherwise, its the same as Value (which defaults to zero). I would double check what was done in the CalendarDatePicker code though.

[robloo]

Also, to emphasize, when the backing type was double we got doubke.NaN for free to support this case. With the switch to decimal for rounding and precision errors that was lost. It was an oversight though. So we already had this functionality of indicating no user selection but then lost it. With that in mind, I dont think people should really vote for not doing anything to fix it.

[grokys]

Is changing back to double not an option?

[robloo]

Double has precision and rounding errors that make it ill suited for currency and other exact input. It just looks bad in some situations too when you increment up and it adds 0.0000000000001 to the value. This could be hidden with some rounding but again this is bad when apps need precise values.

[timunie]

For me it would be an option to have a generic control which can be configured to use double, decimal, int, long,... But that would be a huge change and not an easy task. Otherwise I am with @robloo that precision is better for decimal.

[robloo]

@timunie A generic version of this control with the .NET 7 math interfaces would actually be pretty neat as we discussed in the past. That is probably far in the future though.

[robloo]

I thought of another solution for this. Decimal.NaN doesn't exist which is why we have this issue to begin with. However, Decimal.MinValue and Decimal.MaxValue do. These could be used as special case values and one or both of them treated as empty (like MinValue).

https://docs.microsoft.com/en-us/dotnet/api/system.decimal?view=net-6.0#fields

This shouldn't be an issue because MinValue and MaxValue are so far out of range for user input it wouldn't make sense to have these in the UI anyway.

[robloo]

Yea, I'm just coming up with ideas to try and bridge the gap with those that really don't want this nullable for some reason. Nullability is the best solution though.

[maxkatz6]

Let's go with nullable. But without DefaultValue for now, as it can get forever to agree on it.

[robloo]

@maxkatz6 There is still some debate that can be had for whether the default should be null (and show the placeholder/watermark) or it should be zero. I agree adding a new DefaultValue property is not great in this case.

[maxkatz6]

It was 0 (default for double) before - https://github.com/AvaloniaUI/Avalonia/blob/release/0.10.12/src/Avalonia.Controls/NumericUpDown/NumericUpDown.cs#L124

[timunie]

All right I'll add a new PR which only adds the nullability. That's also what the poll shows most people want.

Let me add something I learned from a similar control in WPF:
We saw in MahApps issues where people that have non-nullable properties complained about it. That was why later DefaultValue was added. Anyway, this can be done later if needed. Another possibility may be to check if the bound property supports null but I don't know if this is even possible and good practice. So for now I'll just make the field nullable. Let's see how it goes 👍