Two Countries Separated by a Common Parser

[bulg]

:( i get 650 sq feet for 4 digits.

[Dan Neely]

I'm paying $450 for that; which is a bit on the high end for the neighborhood because it's a first floor location and the bulk of appartments hereare 2nd story above owner/business. That said, for an unfirnished apt ~1000sqft would only cost $50-100ish more/mo.

Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall

[Ian Shlasko]

The reg key is blank, but nice try :) Believe it or not, this code:

Console.WriteLine("Culture = " + System.Threading.Thread.CurrentThread.CurrentCulture.ToString());
string testString = "12345";
decimal converted = Convert.ToDecimal(testString);
Console.WriteLine("{0} --> {1}", testString, converted);

In a console app targeting .NET 3.5, produces this output:

Culture = en-GB
12345 --> 2345

[Ian Shlasko]

Ahhh, found a permanent fix... The registry key showed up properly, but something was obviously amiss elsewhere... http://social.microsoft.com/Forums/en-US/netfxbcl/thread/4f52ff21-2afe-41c8-aa4e-61acd32dc4a2/ Changed the problem computer's regional settings to something else, then back...

[VentsyV]

If I remember correctly, in UK they use comma as a decimal separator. 1,859,000 to them is invalid so the parser might be getting confused. Did you check if the input contains any commas ?

[Chris Maunder]

Does Your Code Pass The Turkey Test?[^]

cheers, Chris Maunder The Code Project Co-founder Microsoft C++ MVP

[Ian Shlasko]

Nope, not a chance... Only designed to run in the US and UK, since that's where our six-person group has offices. And as I posted in another part of this thread, turned out the problem was his machine... The sPositiveSign reg-key was correctly blank, but somewhere else, the machine had decided that "1" = "+"... I flipped region settings to US and back, and it fixed it.

[Dan Neely]

Nope. I've asked about making it internationalization ready and been nixed from above. If policy ever changes, and it turns out to be a major issue to implement, it's not my fault.

Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall

[Moreno Airoldi]

Ian Shlasko wrote:

APPARENTLY, when you do that on a computer with UK regional settings, it strips out a leading "1" in the translation. No other digits. Just the first "1". "199027" becomes 99027... "1112512" becomes 112512... "100888" becomes 888... I changed it to a double.Parse() and got the same result. Only after explicitly specifying NumberFormatInfo.InvariantInfo did it start to behave.

That's actually "normal". Us Europeans know quite well the hell that can arise from executing our perfectly working code on PCs with different national settings. :P That kind of problem has been there since the beginning, and will most probably be always there (until the one-world, one-set-of-rules utopia, that is). You would be surprised to see how many commercial high profile software projects break up miserably when run on non-US PCs. The correct solution is using the "invariant" culture (or any similar trick in the framework you're using), as you did. I made a rule of always using that, so hopefully my apps won't break (too much) when run on non-Italian PCs... The real mess arises when you exchange data with other systems/softwares, and those are affect by some cultureinfo problem. Imagine for example two different softwares running on an UK PC: the first software won't work unless you set the culture to UK (because of some internals you cannot change which were not programmed with the cultureinfo problem in mind), but exports some data using the invariant culture settings. The second imports the data, but only using the PC's culture settings... all breaks up. You need some ad-hoc middleware to convert the data format.

2+2=5 for very large amounts of 2 (always loved that one hehe!)

[Philipp Sumi]

This is bound to fail with a lot of cultures, as the decimal separator is interpreted depending on cultural settings of the OS every time. If you really have to go through strings, you need to make sure you have a common culture setting for string creation AND parsing: Here's a short snippet that parses a double using the invariant culture settings. If you'd take another culture, the dot might be interpreted differently. Here's a snippet that parses the same string using invariant and German culture settings:

public void TestParsing()
{
NumberFormatInfo provider = CultureInfo.InvariantCulture.NumberFormat;
double d = Convert.ToDouble("12.15", provider);
Console.Out.WriteLine(d);

provider = new CultureInfo("de-de").NumberFormat;
d = Convert.ToDouble("12.15", provider);
Console.Out.WriteLine(d);
}

Output:

12.15
1215

Cheers, Philipp

NetDrives - Open Source Network Share Management

[J4amieC]

VentsyV wrote:

If I remember correctly, in UK they use comma as a decimal separator.

You dont remember correctly, we use the comma as a thousand separator and a decimal point for the decimal separator. Its somewhere weird like Italy that uses the comma as the decimal sep.

[The Real Geek]

I'm from the UK and it doesn't happen for me either :p FYI: if you used FXCop, it would remind you to supply the CultureInfo ;-)