Culture invariant Decimal.TryParse()

Question

I'm writing a custom string to decimal validator that needs to use Decimal.TryParse that ignores culture (i.e. doesn't care if the input contains "." or "," as decimal point separator). This is the suggested method:

public static bool TryParse(     string s,     NumberStyles style,     IFormatProvider provider,     out decimal result ) 

I can't figure out what to use as the 3rd parameter. The examples I've seen look like this:

culture = CultureInfo.CreateSpecificCulture("en-GB"); Decimal.TryParse(value, style, culture, out number) 

so they create a specific culture. CultureInfo does not have a "CreateInvariantCulture" method, and CultureInfo.InvariantCulture is not of the required type. What's the correct usage?

Answer 1

In fact CultureInfo.InvariantCulture can be used here. The parameter expects IFormatProvider, an interface that CultureInfo implements. But InvariantCulture is invariant in the sense that it does not vary with the user's settings.

In fact, there is no culture that accepts either , or . as decimal separator – they are all one or the other. You'll have to find some other way to deal with data which can use either of these decimal separators.

Answer 2

My bad guys. I tested the following code:

        string DutchDecimal = "1,5";         string EnglishDecimal = "1.5";         decimal a;         decimal b;         Console.WriteLine(decimal.TryParse(DutchDecimal, out a));         Console.WriteLine(a);         Console.WriteLine(decimal.TryParse(EnglishDecimal, out b));         Console.WriteLine(b);         Console.Read(); 

and it correctly parses both strings. Seems like the default TryParse is indeed culture invariant. I assumed this was not the case, because the default TypeConversionValidator in EnterpriseLibrary was culture dependent and I assumed it simply used TryParse. However, as it turns out this default parser is hardcoded to use current culture.

EDIT: I found out that "1.5" converts to 1.5 and "1,5" converts to 15. This is actually correct for culture invariant behavior, so there it is. This whole question was apparently spawned by my misunderstanding of how culture invariant works.