CultureInfo.CurrentCulture in number converter causes problems in some countries #5
Comments
|
Thank you for the detailed bug report. To be clear, do you think that our user interfaces should accept user input and report results using CultureInfo.InvariantCulture? I would think that GUIs should use the CurrentCulture and that everything else, like file I/O, should use InvariantCulture. A work-around might be that in Windows, in Control Panel -> Region and Language -> Formats, you could customize the date settings. And in "Additional settings", you could customize the decimal and digit grouping symbols. Would that work for you? We do have clients in France, Netherlands, and the UK, and they apparently haven't run into this problem in the last few years. We did get a report about this issue in October of 2010, and we thought we fixed it, but that was a while ago, and it's easy to make this kind of mistake and not notice it. We'll do some investigations. We have to be careful to not break existing clients. Thanks again. |
|
Thanks for the fast reply. You are right - I jumped to a wrong conclusion when reading the code, I thought the number converter would also be used for writing. I checked again, the output file uses "dots" for float numbers correctly. However, I still think it should be possible to use "dots" for floats also in the gui. When working with floats in technical applications, we often use the "dots". For us using "comma" for float feels awkward and confusing. All our game tools used "dot" so far. But, I cannot speak for other developers, perhaps some prefer it the culture "correct" way. I think it should be up to the developer to decide which one they prefer. Perhaps using a compiler define? Or give the converter and input controls an option? I still found a problem with this in your library which are typical to occur. In the "Grid Property Editor" a vector (float array) is displayed with a comma as field separator. With German local settings a vector (1.7, 1.5, 1.1) is now displayed as "1,7,1,5,1,1". You can easily reproduce this with the DomTreeEditor Sample. Well, your library is really great, and as it is open source, I just changed it to how I prefer it. So it is no big issue for me. |
1. Skinning improvements. Try these out in the TimelineEditor using commands in the View menu. (Alan) * Fixed a few issues with CustomColorTable and specify more override in sample skin. * Updated UI type editor to accept skin. * Skin is now applied to all property editing controls that are returned from IPropertyEditor.GetEditingControl(). * Bug fix: toolbar button highlight and toggle status were broken when applying non-default skin. * Bug fix: disabled SetFont in PropertyView because it was causing SkinService to throw exception due to cloning a disposed font. * Bug fix: apply skin was clearing output panel. * Added FormNcRenderer to renders non-client areas (title bar, form border, caption buttons, form icon, and title text). * Removed border from ConsoleTextBox. * Updated Dark.skn and Light.skn. * Fixed a one pixel off drawing error PropertyGridView. * Removed onpaint method in PropertyEditingControl. * Removed border from ListBox used in HistoryLister. * Minor tweak to LongEnumControl. 2. Reviewed, added, or improved all public and protected member comments in Framework and Samples directories. Made changes to 343 code files. (gstaas) 3. Provided a Shell type drag drop interface to a drag drop action. Calling the right methods on a form makes it show the icons from the shell (so the images when you drag a file over explorer for example), but also allows you to attach your own image to a drag drop action when initiating a drag drop. (Tom) 4. DefaultTabCommands: fixed a problem where sub-document windows (like circuit group windows) could cause a crash, because the control's description was an illegal path name (e.g., "Untitled:Group"). (Ron) 5. Allow for the creation of a TextLayout using a transformation matrix. (Tom) 6. Added method to get the bounds from a D2dGeometry. (Tom) 7. New version of SharpDX, based off of the 2.5.0 Stable release. (Tom) 8. Most math classes, like Vec3F, have had their ToString() methods improved to work with European languages and to have more consistent behavior. The main problem was that in languages that use a ‘,’ as a decimal point, then a ‘;’ should be used to separate numbers in a list. Previously, a ‘,’ was hard-coded to separate numbers in a list regardless of the current culture setting. Addresses issue #5. (Ron) * Added StringUtil.GetNumberListSeparator(IFormatProvider). * FloatArrayConverter: now uses the appropriate number separator (e.g., ',' or ';') depending on the current culture. * Past behavior: ToString() is not valid for European cultures for either persistence or GUI. In English, it’s valid for persistence and GUI. ToString(null, null) is the same as ToString(). ToString(“G”, englishCulture) is valid for GUIs in English. Parentheses are added. Float is converted to double prior to printing. ToString(“G”, euroCulture) is not valid for GUIs anywhere. Parentheses are added. Float is converted to double prior to printing. ToString(“R”,CultureInfo.InvariantCulture) is valid for persistence everywhere. Parentheses are added. Float is converted to double prior to printing. * Now: ToString() is valid for GUI in all cultures. In English, it’s valid for persistence and GUI. ToString(null, null) is the same as ToString(). ToString(“G”, englishCulture) is valid for GUIs in English. ToString(“G”, euroCulture) is valid for GUIs in Europe. ToString(“R”,CultureInfo.InvariantCulture) is valid for persistence everywhere. 9. Make CircuitValidator no longer require the adapted DomNode also support ReferenceValidator( CTE does not need ReferenceValidator because its wires are set up very differently and specially handled) (Shen)
|
I addressed this problem and some related ones: |
In some countries, like Germany, the official separator for numbers is comma and not a dot, e.g. we write "3,7" instead of "3.7".
Unfortunately in C# the float or double to string converter takes this into account if you use "CultureInfo.CurrentCulture". The result is, that in Germany you can only enter numbers with comma and the data files are written with comma. By that the data files become not exchangeable between computers with different culture settings.
Furthermore, even though the official number separator in Germany is a comma, we still use the international dot in computer science.
To avoid this problem, C# has the following culture info setting:
"CultureInfo.InvariantCulture"
If you exchange "CultureInfo.CurrentCulture" with "CultureInfo.InvariantCulture" the number separator will always be a dot.
Therefore I suppose that in the entire framework you change this at every function where a number conversion is made.
This way the framework will work in countries like Germany as expected.
The text was updated successfully, but these errors were encountered: