RadzenNumeric with TValue set to double does not correctly increment with the step up or step down buttons #1362

New Issue

claunia · 2026-01-29T17:52:37Z

claunia commented

2026-01-29 17:52:37 +00:00

Originally created by @Daeymon on GitHub (Aug 22, 2024).

Step up or step down on RadzenNumeric is adding additional tiny decimals to the number on top of the designated step amount when TValue is set to "double".

To reproduce add the following to a default Radzen enabled Blazor project and click the step up or step down button a few times. The additional decimal doesn't get added on every step.

<RadzenNumeric TValue=double? Value=0.1 Step="0.1" />

...press step up twice and then .....

This started happened after NuGet version 4.32.9 and is still happening in 5.1.2.

Originally created by @Daeymon on GitHub (Aug 22, 2024). Step up or step down on RadzenNumeric is adding additional tiny decimals to the number on top of the designated step amount when TValue is set to "double". To reproduce add the following to a default Radzen enabled Blazor project and click the step up or step down button a few times. The additional decimal doesn't get added on every step. ``` <RadzenNumeric TValue=double? Value=0.1 Step="0.1" /> ``` ![image](https://github.com/user-attachments/assets/1ba96e7b-137e-4827-a3ba-6b91a2c80568) ...press step up twice and then ..... ![image](https://github.com/user-attachments/assets/12b386fe-6852-4f83-aea2-ded3a470fe7a) This started happened after NuGet version 4.32.9 and is still happening in 5.1.2.

claunia closed this issue

2026-01-29 17:52:38 +00:00

claunia commented

2026-01-29 17:52:38 +00:00

@enchev commented on GitHub (Aug 23, 2024):

Looks like it's caused by this pull request: 98967410cb
I'll check how to fix it.

UPDATE: Before this change the Numeric component calculated new value with step only using decimal type exactly to avoid such problems. For example the result of (double)0.2 + (double)0.1 will be 0.30000000000000004, now the Numeric component will use TValue to perform the calculation and as a result we have floating-point value loss of precision. More info can be found here: https://stackoverflow.com/questions/5903003/addition-of-double-values-inconsistent

@enchev commented on GitHub (Aug 23, 2024): Looks like it's caused by this pull request: https://github.com/radzenhq/radzen-blazor/commit/98967410cb38d115e9a4bb0e1db4ac5aa22ae151 I'll check how to fix it. UPDATE: Before this change the Numeric component calculated new value with step only using decimal type exactly to avoid such problems. For example the result of `(double)0.2 + (double)0.1` will be `0.30000000000000004`, now the Numeric component will use TValue to perform the calculation and as a result we have floating-point value loss of precision. More info can be found here: https://stackoverflow.com/questions/5903003/addition-of-double-values-inconsistent

claunia commented

2026-01-29 17:52:38 +00:00

@Cosmatevs commented on GitHub (Aug 25, 2024):

I think that there were two solutions to this problem:

Use decimal instead of double or float if you need decimal precision. double and float types are meant to be approximations.
Use the Format attribute to show only some decimal places, and round the value when needed.

@enchev Converting floats and doubles to decimals will certainly work in most cases. However, decimal is not able to represent the full range of float and double types. For this reason, you may lose precision for numbers really close to zero and get conversion errors for large numbers. I'm not sure if this is intended – I was just concerned after seeing your commit.

@Cosmatevs commented on GitHub (Aug 25, 2024): I think that there were two solutions to this problem: 1. Use `decimal` instead of `double` or `float` if you need decimal precision. `double` and `float` types are meant to be approximations. 2. Use the `Format` attribute to show only some decimal places, and round the value when needed. @enchev Converting floats and doubles to decimals will certainly work in most cases. However, `decimal` is not able to represent the full range of `float` and `double` types. For this reason, you may lose precision for numbers really close to zero and get conversion errors for large numbers. I'm not sure if this is intended – I was just concerned after seeing your commit.

claunia commented

2026-01-29 17:52:38 +00:00

@enchev commented on GitHub (Aug 25, 2024):

Feel free to propose better solution.

@enchev commented on GitHub (Aug 25, 2024): Feel free to propose better solution.

claunia commented

2026-01-29 17:52:39 +00:00

@Cosmatevs commented on GitHub (Aug 26, 2024):

@enchev I've already suggested two user-side solutions 😅 I think that it wasn't a problem with the Radzen component, it was just unrealistic expectations about the double and float types. Therefore, in my opinion, the responsibility for using appropriate types or solutions should lie with the developers using Radzen components, not with the developers of the Radzen. But that's just my opinion – perhaps there are better reasons to actually convert floating types to decimal.

@Cosmatevs commented on GitHub (Aug 26, 2024): @enchev I've already suggested two user-side solutions 😅 I think that it wasn't a problem with the Radzen component, it was just unrealistic expectations about the `double` and `float` types. Therefore, in my opinion, the responsibility for using appropriate types or solutions should lie with the developers using Radzen components, not with the developers of the Radzen. But that's just my opinion – perhaps there are better reasons to actually convert floating types to `decimal`.

claunia referenced this issue

2026-01-29 18:20:02 +00:00

[PR #1363] [MERGED] #1362 - RadzenDataFilter operator not being set using AddFilter #2690

claunia referenced this issue

2026-01-29 18:20:03 +00:00

[PR #1363] #1362 - RadzenDataFilter operator not being set using AddFilter #2695

Sign in to join this conversation.