Parsing Decimal Separators

[LoSboccacc]

but why use decimal separators to begin with? can't something like picking the rightmost [,.] as comma separator and ignore the rest work?

[Zhatelier]

but why use decimal separators to begin with? can't something like picking the rightmost [,.] as comma separator and ignore the rest work?

That would require every number to have a decimal separator or the game would confuse 76,000 as 76 and not 76k. Naturally, my personal preference is the thousands separator to be just space and have the decimal be either of the two, less prone for misinterpretation, but it would force everyone to use that instead of what people are used to.

[mike2R]

I'm a little lost on the exact problem here. Ideally:

- Whenever Aurora is reading a string from the UI to transform it into a number in memory, it should use the culture of the computer where the software is running.
- Whenever Aurora is printing a number in memory to the UI, it prints it using the culture of the computer where it is running.

If the DB is storing some numbers as strings with a particular separator, then writing or reading those strings from the DB to a number in memory should be done with whatever culture the DB is expecting. This means that Aurora may need two different code paths to handle transforming between strings and numbers if the DB culture and the user culture are different.

The only problem would be if the DB has a number stored as a string, and then that goes directly to the UI without being transformed to a number in memory, or viceversa. Those cases would need to be changed so there's a middle transformation to a number so the correct culture is applied.

This is kind of where my understanding of the problem has got to.  C#, by default, is doing everything localised.  All the methods that transform a string into a number, or a number into a string, are all going to use the user's culture unless they are specifically told not to.  So it should all be transparent to the developer.

The only way I can see these problems happening, are numeric string literals, hardcoded either in the db or the code, that are being put directly to the UI.  Solving this would seem to be the way to fix it, rather that writing your own number parsing routines.

Or just stop C# from localising at all (which is the current solution, except the user is doing it manually by changing their system settings).  Which I believe is pretty trivial, though I admit I've never done it.  This article:

https://csharp.net-tutorials.com/working-with-culture-and-regions/application-culture-and-uiculture/

Seems to suggest you can set the entire application's culture with a one-liner.

[AlitarSemiramis]

This is kind of where my understanding of the problem has got to.  C#, by default, is doing everything localised.  All the methods that transform a string into a number, or a number into a string, are all going to use the user's culture unless they are specifically told not to.  So it should all be transparent to the developer.

The only way I can see these problems happening, are numeric string literals, hardcoded either in the db or the code, that are being put directly to the UI.  Solving this would seem to be the way to fix it, rather that writing your own number parsing routines.

Or just stop C# from localising at all (which is the current solution, except the user is doing it manually by changing their system settings).  Which I believe is pretty trivial, though I admit I've never done it.  This article:

https://csharp.net-tutorials.com/working-with-culture-and-regions/application-culture-and-uiculture/

Seems to suggest you can set the entire application's culture with a one-liner.

Yes, C# Parse and ToString by default use the user culture, you can see it in the source code directly, for example for double:

https://referencesource.microsoft.com/#q=double

You can see that ToString, Parse and TryParse all use NumberFormatInfo.CurrentInfo; and CurrentInfo is getting its culture from CurrentThread.CurrentCulture.

[Bartimeus]

Hello,

I just to say thanks to you Steve for working on this topic. Hope it will work out !
My only problem with installing aurora back in the VB6 was those separator