Windowscommunitytoolkit: TextBoxRegex Not Localized for Decimal (Fixed to InvariantCulture)

[robloo]

I'm submitting a...

• Bug report (I searched for similar issues and did not find one)

Current behavior

The TextBoxRegex extension with ValidationType="Decimal" does not support all UI cultures. Instead it's fixed to InvariantCulture. In English decimal values are "10.1234" with a period. In Spanish or German decimal values are written "10,1234". Parsing the English will be correct; however, Spanish or German user input will just be "101234" with the fractional portion lost.

Full Details

I'm using the TextBoxRegex extensions (XAML following), which are overall great. However, decimal validation is not localized.

ToolkitExtensions:TextBoxRegex.ValidationMode="Dynamic"
ToolkitExtensions:TextBoxRegex.ValidationType="Decimal"

That's fine for other types (phone number) where a regex expression can be provided. However, the decimal validation relies on the string extension below StringExtensions.cs:

public static bool IsDecimal(this string str)
{
    return decimal.TryParse(str, NumberStyles.Number, CultureInfo.InvariantCulture, out decimal _decimal);
}

As you can see this assumes an InvariantCulture which means validating for other number types like Spain/Spanish (1.234,56) is broken. InvariantCulture has the NumberDecimalSeparator and NumberGroupSeparator fixed to "." and "," respectively.

To fix this I recommend passing an IFormatProvider to the IsDecimal function and then passing it the CurrentUICulture (although a case could be more for CurrentCulture too).

public static bool IsDecimal(this string str, IFormatProvider provider = null)
{
    return decimal.TryParse(str, NumberStyles.Number, provider, out decimal _decimal);
}

Since provider is an optional parameter it won't break any existing API calls. Another method could also be added to overload .IsDecimal().

Then in TextBoxRegex.cs

```csharp
private static void ValidateTextBox(TextBox textbox, bool force = true)
{
// Code removed
case ValidationType.Decimal:
regexMatch = textbox.Text.IsDecimal(Thread.CurrentThread.CurrentUICulture);
break;
// Code removed

## Expected behavior

Handle user input in any UI culture. "10.1234" with a period and "10,1234" with a comma (when UI culture's number format info is set correctly) both parse as "10.1234"

## Minimal reproduction of the problem with instructions

Use a TextBoxRegex as below. But change the UI language to Spanish (Spain) or German and enter "10,1234". The decimal is incorrectly parsed using the InvariantCulture instead of UI culture.

ToolkitExtensions:TextBoxRegex.ValidationMode="Dynamic"
ToolkitExtensions:TextBoxRegex.ValidationType="Decimal"
```

Environment

All will TextBoxRegex extensions

[robloo]

Another issue here with Decimal validation: when the user starts by typing a negative "-", the negative sign is recognized as invalid and cleared. A negative sign is only allowed after a number has already been typed. This is not very user friendly. Negative signs (in a localized way) need to be a special case and allowed without other characters.

[DkmS1953]

Another issue here with Decimal validation: when the user starts by typing a negative "-", the negative sign is recognized as invalid and cleared. A negative sign is only allowed after a number has already been typed. This is not very user friendly. Negative signs (in a localized way) need to be a special case and allowed without other characters.

Same story with "." and "," in the first position

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[robloo]

This should not be closed. This is a real issue that affects not only localization but basic decimal or negative input. Absolutely this must be addressed or it's unusable in production.

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[DkmS1953]

It is very convenient for developers – it was silent for two weeks, the issue has closed, it is possible to go to the cashier for a prize.

[robloo]

@nmetulev Please change the system from auto-closing issues like this. For this one specifically, if you need someone to work on it I can take a swing at it over the next few weeks. We haven't heard a thing from a maintainer though so don't want any effort to go to waste.

[windowstoolkitbot]

This issue seems inactive. It will automatically be closed in 14 days if there is no activity.

[Kyaa-dost]

@robloo I know it's been a while but do you want to work on this issue? Or was there any alternative path decided to move forward?

[robloo]

I was waiting for feedback on how best to address this. Reguardless, it fell off the radar a while ago and was forgotten about. I dont plan to work on this anymore and the NumberBox is used instead.