-1

So as I've stated in my question I recently wrote a small program to calculate the amount of bricks needed to build a room, using the following

 float result = ((fLenght * fWitdh) * fHeight) * bricksPerMeter;

When Running a test case on both my main computer and a second computer they come up with a different answer

Ex: PC 1 ((15 * 1)* 1.8)* 40 = 1080

PC 2 with the same values produces 600 as the answer

now the error is fixed by changing the decimal symbol on the second computer

I want to know if there is anyway for my code to check if this is the case and attempt to fix it without me going to each computer and setting it manually

Pike
  • 31
  • 5
  • 1
    _"now the error is fixed by changing the decimal symbol on the second computer"_ - huh? I feel like we must be missing some information here. – ProgrammingLlama Sep 09 '21 at 14:15
  • Okay the decimal symbol on the main computer is a point and on the second one its a comma by changing the symbol to be matching on both machines it worked if you want. i can link the github page it like 60 lines of code total – Pike Sep 09 '21 at 14:19
  • No, I understood that. I can only see this being an issue if you're taking user input in., but we don't see any evidence of that in your question, or any code for interpreting user input as a numeric value. – ProgrammingLlama Sep 09 '21 at 14:19
  • Bottom line is: once you have a `float` or a `double` in .NET, it doesn't matter what the current culture's decimal separator is because it has nothing to do with these types. It only matters when you interpret a string as a number, or format a number as a string. – ProgrammingLlama Sep 09 '21 at 14:21
  • Yes the user has to input the values sorry I didn't include that in the question they input the height length and width and select a radial button for the type of brick – Pike Sep 09 '21 at 14:21
  • 1
    OK, so how do you interpret (parse) the numbers? And why do you want to enforce a different way of parsing the numbers? Generalisation: on a German computer the decimal separator is a comma, and a German would feel perfectly at home inputting a decimal value in this way. On an British English computer, the decimal separator is a period, and a British English user would feel perfectly at home inputting a decimal in that way. – ProgrammingLlama Sep 09 '21 at 14:22
  • I'm using float.TryParse(value, out fValue) ? fValue : 1f – Pike Sep 09 '21 at 14:23
  • I'm trying to find a good duplicate, but you can force `.` by passing `CultureInfo.InvariantCulture` to `TryParse`. – ProgrammingLlama Sep 09 '21 at 14:25
  • 1
    Seems like you should be using `float.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, out fValue);` – Matthew Watson Sep 09 '21 at 14:26
  • Thanks I'll try that I think that might have been my problem – Pike Sep 09 '21 at 14:28
  • Are you sure you want to make that change? If the default culture is, for example, German (Germany), then the default culture within your application will be German (Germany). This seems the correct way to go for a German user. It seems like the existing behaviour is the most correct. – ProgrammingLlama Sep 09 '21 at 14:30
  • I just had a look at the local on both systems one was on English and the other Japanese – Pike Sep 09 '21 at 14:39
  • If it's the Japanese one then that's rather odd. I wonder if someone had configured the system like that for a reason. – ProgrammingLlama Sep 09 '21 at 14:42
  • I think it's a mistake both are home computers i just wanted to make life a bit easier by removing one of the calculations that has to be done nearly daily and ran into this issue didn't even know that different locals can cause problems – Pike Sep 09 '21 at 14:45
  • If it's serialised data that you're dealing with, you should normally use the InvariantCulture when serialising and deserialising - but if it's a string that's come from the user via the UI you normally use CurrentCulture. – Matthew Watson Sep 09 '21 at 15:13

1 Answers1

3

Normally when you launch a .NET application, it takes its default culture settings from the operating system. That is to say that computer configured for German (Germany) would result in the de-de culture being used in the application, and a computer configured for English (United Kingdom) would result in the en-gb culture being used in the application.

With these cultures come things like date format strings, decimal separators, etc. which is where your issue comes from.

A simple solution is to change your code, which is currently:

float.TryParse(value, out fValue) ? fValue : 1f

to use the Invariant Culture:

float.TryParse(value, NumberStyles.Any, CultureInfo.InvariantCulture, out fValue) ? fValue : 1f;

This will then use the invariant culture, whose decimal separator is ., to parse the string to a float.

Note that you'll probably want to enforce a culture when you convert the result back to a string. One way to do this is by passing a culture to the .ToString method:

string resultText = result.ToString(CultureInfo.InvariantCulture);
Console.WriteLine(resultText);

Alternative solution (but not recommended): you could override the default culture for your entire application but that might cause problems for you elsewhere, so I don't recommend this.

ProgrammingLlama
  • 36,677
  • 7
  • 67
  • 86