Handeling currency values with the decimal place denoted by a period or comma

BrokenArrows

From my previous thread about changing the regional settings i have run into another issues about handeling currency.

I am receiving a currency value as a string from a 3rd party. Their values can be formatted as comma separated or period separated values. eg ( 12.34 or 12,34)

I also want to handle currency from places with more than 2 decimal places. eg. (12.345 or 12,345)

Thousands will be separated like ( 1,234.56 or 1.234,56 or the same with 3 decimal places)

Convert.ToDecimal is throwing an exception when the number format is not the same as the regional settings of the server.


System.FormatException: Input string was not in a correct format.
at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
at System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
at System.Convert.ToDecimal(String value)

Colonel Panic

Is your workflow "get exception, post on boards"?

What have you tried? Did you read the documentation? I'm pretty sure there's an overload of GetDecimal that takes an IFormatProvider. Are you using that?

BrokenArrows

Colonel Panic wrote: »

Is your workflow "get exception, post on boards"?

What have you tried? Did you read the documentation? I'm pretty sure there's an overload of GetDecimal that takes an IFormatProvider. Are you using that?

Its not like i stop trying to work it out after i post on boards!!!

I thought of using the IFormatProvider overload but the problem is i cant know what culture the decimal is coming from, it wont necessarly be the same as the server.

Colonel Panic

The sample for the IFormatProvider overload does what you want! It fills an array of CultureInfo objects for each culture/locale it wants to handle and tries to convert the incoming amounts handling the exceptions on the way.

seamus

You need to have some way of identifying the locale/format of the incoming data, otherwise you risk generating garbage.

As you point out yourself;
"I also want to handle currency from places with more than 2 decimal places. eg. (12.345 or 12,345)"

This means that if the incoming data contains no format/locale identifier, then any method you use which attempts to convert the above two strings by "guessing" could be incorrect by a factor of 1,000.

It's really only an issue for values up to 999.999 (and with exactly 3 decimal places), but it's an issue.

BrokenArrows

seamus wrote: »

You need to have some way of identifying the locale/format of the incoming data, otherwise you risk generating garbage.

As you point out yourself;
"I also want to handle currency from places with more than 2 decimal places. eg. (12.345 or 12,345)"

This means that if the incoming data contains no format/locale identifier, then any method you use which attempts to convert the above two strings by "guessing" could be incorrect by a factor of 1,000.

It's really only an issue for values up to 999.999 (and with exactly 3 decimal places), but it's an issue.

Ya ill have to get onto the 3rd party to see if they can send me a culture identifier to avoid these issues.