0

When I upgrade my C# project from net 4.5.2 to 4.6, my project fails to run properly on windows machines in regions where the numberformat uses a comma as a decimal point. I can fix it if I apply the cultureinfo numberformat to every single .ToString and float.Parse and double.Parse. (as I move values back and forth between floating and text)

Is there a statement I can add so the entire project uses the current machines numberformat?

user3604790
  • 1
  • 1
  • 1
    What do you mean by "current machine"? *Your machine* where you are compiling or the *client's machine*, ie where the code is running? And I'm pretty sure, also .net 4.5 formatted strings according to the machines locale settings. – derpirscher Nov 19 '21 at 15:26
  • 1
    I'm not aware of a change in 4.6 that would cause this. ToString and Parse should always use the current culture if one is not specified, so something else must have changed. Could you post a minimal example of code that has this problem in 4.6 but not 4.5? – juharr Nov 19 '21 at 15:29
  • if you *really* want to set a fixed culture for you app (I'm not so sure that's a good idea) you could for instance use https://stackoverflow.com/questions/468791/is-there-a-way-of-setting-culture-for-a-whole-application-all-current-threads-a – derpirscher Nov 19 '21 at 15:30
  • 1
    What you claim isn't true. *All* .NET versions since 1.0 work the same when it comes to culture. `my project fails to run properly on windows machines in regions where the numberformat uses a comma as a decimal point.` that means your code has a bug and assumes the same decimal point is used in all countries. If you let .NET just use the current user's locale settings everything will work just fine. If you want to force a specific format no matter what the local culture is then yes, you need to either specify that culture everywhere or set `Thread.CurrentCultureInfo`. – Panagiotis Kanavos Nov 19 '21 at 15:37
  • The real problem you describe, how to handle localized input, is nothing new and doesn't require hard-coding cultures. All desktop and web apps encounter this once they try to work with multiple cultures. It's so common it's actually part of the .NET certification tests. What kind of application are you building? Desktop? Web? What does your code do? Where does the text input come from? A textbox? Have you considered using a numeric textbox instead? Are the users using dots as decimals even when their culture specifies commas? You could use a masked box or key events to prevent bad input – Panagiotis Kanavos Nov 19 '21 at 15:44
  • For example, you could use a keyboard event to prevent users from entering the current culture's thousand separator. Or you could use a masked text box that would make it clear to the user what's expected. If you use a numeric text box the user won't be able to enter invalid data. With dates, you can use a Date Picker control to ensure users enter the correct date – Panagiotis Kanavos Nov 19 '21 at 15:45
  • For web apps, the HTML `input` element has support for numbers and dates, returning the value as an unambiguous value. [input type='number'](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number) returns a `Number` object. [input type='date'](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date) returns the selected date in the ISO8601 format – Panagiotis Kanavos Nov 19 '21 at 15:49
  • Panagiotis, my project is for a class of SDR. github.com/ke9ns/PowerSDR_ke9ns_v2.8.0/ is a Windows desktop program. Its an old open source project Yes I agree. I want NET to just use the current locale settings. Example: The user will enter frequencies as 7,200 mhz in Sweden and a user in the USA will enter as 7.200 mhz. And the XML database that stores data and calibration data will reflect the locale. So the database files between the 2 users are not compatible, but that is OK. But under Net 4.6 it no longer works, so I must have something set incorrectly. – user3604790 Nov 20 '21 at 01:35

1 Answers1

0

My solution have been to use custom parse functions that are more lenient regarding decimal separator, accepting both dot and comma. I have done this since at least .net 3, so I would not think that the behavior has changed.

At least for cultures where not both are used. i.e. Using one for decimal separator and the other for number group separator. For example Germany and US, that to top it of uses the inverse meaning of the separators.

I find it quite irritating that this is not handled better by the default parser, since roughly half the software and data uses dot as the decimal separator regardless of culture. My specific culture uses comma as decimal separator and space as a thousand separator. So a dot in a number is quite unambiguously a decimal separator, even if it is technically incorrect.

JonasH
  • 28,608
  • 2
  • 10
  • 23