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

New Issue

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

claunia commented

2026-01-29 17:42:13 +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 closed this issue

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

claunia commented

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

@MPapst commented on GitHub (Mar 8, 2023):

You could use the Format property to define a format in your own that then is used for parsing and formatting.

@MPapst commented on GitHub (Mar 8, 2023): You could use the Format property to define a format in your own that then is used for parsing and formatting.

claunia commented

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

@JohannesGESchmidt commented on GitHub (Nov 27, 2023):

This is still happening, does anyone have another workaround ? @MPapst you solution didn't work.

@JohannesGESchmidt commented on GitHub (Nov 27, 2023): This is still happening, does anyone have another workaround ? @MPapst you solution didn't work.

claunia commented

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

@pianomanjh commented on GitHub (Jan 10, 2024):

If this is a bug, it is a bug in .NET. The following decimal.Parse code demonstrates the same behavior without Radzen.

var s = "45.67";
var ci = CultureInfo.GetCultureInfo("de-DE");
var result = decimal.Parse(s, NumberStyles.Number, ci);
// result is 4567

@pianomanjh commented on GitHub (Jan 10, 2024): If this is a bug, it is a bug in .NET. The following decimal.Parse code demonstrates the same behavior without Radzen. ``` var s = "45.67"; var ci = CultureInfo.GetCultureInfo("de-DE"); var result = decimal.Parse(s, NumberStyles.Number, ci); // result is 4567 ```

claunia commented

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

@JohannesGESchmidt commented on GitHub (Jan 10, 2024):

@pianomanjh
You have it backwards, as a German you enter 45,67 into the radzen control and expect it to be saved as 45.67 but it saves it as 4567.

.NET itself does not have the bug (notice the comma as decimal separator):
var s = "45,67";
var ci = CultureInfo.GetCultureInfo("de-DE");
var result = decimal.Parse(s, NumberStyles.Number, ci);

Console.WriteLine($"result: {result}");
// result is 45.69

@JohannesGESchmidt commented on GitHub (Jan 10, 2024): @pianomanjh You have it backwards, as a German you enter 45,67 into the radzen control and expect it to be saved as 45.67 but it saves it as 4567. .NET itself does not have the bug (notice the comma as decimal separator): var s = "45,67"; var ci = CultureInfo.GetCultureInfo("de-DE"); var result = decimal.Parse(s, NumberStyles.Number, ci); Console.WriteLine($"result: {result}"); // result is 45.69

claunia commented

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

@pianomanjh commented on GitHub (Jan 11, 2024):

ah, ok. The Culture is not being applied. RadzenNumeric gives preference to a CascadingParameter called DefaultCulture, and if that isn't set uses the CurrentCulture.

It behaves properly in the sample if the culture is manually applied. (replace and run with this:

@using System.Globalization

<div class="rz-p-12 rz-text-align-center">
    <RadzenNumeric Culture=@culture Placeholder="0.0" Step="0.5" @bind-Value=@value InputAttributes="@(new Dictionary<string,object>(){ { "aria-label", "enter value" }})" />
</div>

@code{
    double? value;
    CultureInfo culture = CultureInfo.GetCultureInfo("de-DE");
}

If using Blazor Server, I imagine the culture applied will be that of the machine hosting it. I'm not sure if Radzen has a solution for applying the correct culture based on the user's machine.

@pianomanjh commented on GitHub (Jan 11, 2024): ah, ok. The Culture is not being applied. `RadzenNumeric` [gives preference](https://github.com/radzenhq/radzen-blazor/blob/ad6fbe2bf3b41d1860951c59c4879b647735f6ee/Radzen.Blazor/RadzenComponent.cs#L52) to a `CascadingParameter` called `DefaultCulture`, and if that isn't set uses the `CurrentCulture`. It behaves properly in the sample if the culture is manually applied. (replace and run with this: ``` @using System.Globalization <div class="rz-p-12 rz-text-align-center"> <RadzenNumeric Culture=@culture Placeholder="0.0" Step="0.5" @bind-Value=@value InputAttributes="@(new Dictionary<string,object>(){ { "aria-label", "enter value" }})" /> </div> @code{ double? value; CultureInfo culture = CultureInfo.GetCultureInfo("de-DE"); } ``` If using Blazor Server, I imagine the culture applied will be that of the machine hosting it. I'm not sure if Radzen has a solution for applying the correct culture based on the user's machine.

claunia commented

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

@akorchev commented on GitHub (Jan 11, 2024):

Indeed, it seems your application is not properly localized. .NET will behave in the same way unless the current culture is set.

@akorchev commented on GitHub (Jan 11, 2024): Indeed, it seems your application is not properly localized. .NET will behave in the same way unless the current culture is set.

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#721