RadzenNumeric removes decimal separator that does not match culture/locality, thus multiplying the value. #718

New Issue

claunia · 2026-01-29T17:42:10Z

claunia commented

2026-01-29 17:42:10 +00:00

Originally created by @nscherm98 on GitHub (Feb 7, 2023).

Describe the bug
First off: I'm not entirely sure if this is a bug or counts as expected behaviour so please excuse, if I got it wrong. When using RadzenNumeric the decimal separator is determined by the environment's CultureInfo / locality. For me that is Germany, which means RadzenNumeric expects comma as decimal separator. If the user enters a decimal point (which is also common in technical contexts, even in Germany), the point is removed after tabbing out of the field, thus multiplying the value by 10 to the power of the number of decimal digits.

To Reproduce
Steps to reproduce the behavior:

Go to https://blazor.radzen.com/numeric
Click into field Placeholder and 0.5 step
Type any decimal number, e.g. 12.34 (note: you might have to enter 12,34 depending on your locality to reproduce this)
Tab out of the field
The value is now converted to 1234, i.e. it got multiplied by factor 100

Expected behavior
I would expect RadzenNumeric to replace the 'invalid' decimal separator by the one which is common for the system's locality.
It would be even better if there was a flag (like a bool) that let's you tell RadzenNumeric not to consider the system's locality and instead provide a specific decimal separator ("Format" kind of let's you do that, but has the same issue when using a different separator). Any other separator should then be converted to the defined one. There should not be any unwanted multiplication.

Screenshots
Enter number using different decimal separator

After moving out of the field the value is converted

Desktop

OS [Windows 10 Professional]
Browser [Google Chrome]
Version [109.0.5414.120]

Additional context
As it cannot be guaranteed that users of our software only use comma as decimal separator, it poses a problem that inputs using dot as decimal separator are automatically increased by several magnitudes. Especially if a user does not pay close attention, thus not realising their input is faulty.
This problem is even bigger when considering another (already known) issue, where you can click back into a field, edit it, tab out again and the format is not applied again (apparently only when using @bind-value which is required in our use case). That means the field shows the correct value (e.g. 12.34) which then is converted (e.g. to 1234) without the user even noticing.

Originally created by @nscherm98 on GitHub (Feb 7, 2023).  **Describe the bug** First off: I'm not entirely sure if this is a bug or counts as expected behaviour so please excuse, if I got it wrong. When using RadzenNumeric the decimal separator is determined by the environment's CultureInfo / locality. For me that is Germany, which means RadzenNumeric expects comma as decimal separator. If the user enters a decimal point (which is also common in technical contexts, even in Germany), the point is removed after tabbing out of the field, thus multiplying the value by 10 to the power of the number of decimal digits. **To Reproduce** Steps to reproduce the behavior: 1. Go to https://blazor.radzen.com/numeric 2. Click into field _Placeholder and 0.5 step_ 3. Type any decimal number, e.g. 12.34 (**note**: you might have to enter 12,34 depending on your locality to reproduce this) 4. Tab out of the field 5. The value is now converted to 1234, i.e. it got multiplied by factor 100 **Expected behavior** I would expect RadzenNumeric to replace the 'invalid' decimal separator by the one which is common for the system's locality. It would be even better if there was a flag (like a bool) that let's you tell RadzenNumeric not to consider the system's locality and instead provide a specific decimal separator ("Format" kind of let's you do that, but has the same issue when using a different separator). Any other separator should then be converted to the defined one. There should not be any unwanted multiplication. **Screenshots** Enter number using different decimal separator ![image](https://user-images.githubusercontent.com/119601658/217200170-4f62101f-3180-44dd-848c-a49ce9052048.png) After moving out of the field the value is converted ![image](https://user-images.githubusercontent.com/119601658/217200263-cc6f48fd-aac7-4e64-b513-fb33840cbe60.png) **Desktop** - OS [Windows 10 Professional] - Browser [Google Chrome] - Version [109.0.5414.120] **Additional context** As it cannot be guaranteed that users of our software only use comma as decimal separator, it poses a problem that inputs using dot as decimal separator are automatically increased by several magnitudes. Especially if a user does not pay close attention, thus not realising their input is faulty. This problem is even bigger when considering another (already known) issue, where you can click back into a field, edit it, tab out again and the format is not applied again (apparently only when using @bind-value which is required in our use case). That means the field shows the correct value (e.g. 12.34) which then is converted (e.g. to 1234) without the user even noticing.

claunia referenced this issue

2026-01-29 18:18:09 +00:00

[PR #718] [MERGED] Fix typos in documentation regarding CSS snippets #2296

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#718