Units go wrong on one computer not the other

[fv3]

Hey,

 maybe this isn’t a Revit API issue but maybe anyone else had this problem… we have a list of strings that we convert to a double. For example.

Convert.ToDouble("7.5")

then with

UnitUtils.ConvertToInternalUnits(7.5, UnitTypeId.Meters)

for most computers this works fine, but we have 1 computer where it doesn’t… it makes it 100x bigger the value in feet???

we checked in windows the region / decimal settings all the same… signed in as a different user but no luck… reinstalled revit 2022.

 Anyone who might have a solution?!

 Kind regards,

 Fabian

[fv3]

Hey,

 maybe this isn’t a Revit API issue but maybe anyone else had this problem… we have a list of strings that we convert to a double. For example.

Convert.ToDouble("7.5")

then with

UnitUtils.ConvertToInternalUnits(7.5, UnitTypeId.Meters)

for most computers this works fine, but we have 1 computer where it doesn’t… it makes it 100x bigger the value in feet???

we checked in windows the region / decimal settings all the same… signed in as a different user but no luck… reinstalled revit 2022.

 Anyone who might have a solution?!

 Kind regards,

 Fabian

[jeremy_tammik · Accepted solution]

If you are using Convert and your OS has anything to do with German-speaking regions or other interesting Culture settings, then that might be the culprit:

• https://stackoverflow.com/questions/11399439/converting-string-to-double-in-c-sharp#11399479

[jeremy_tammik · Accepted solution]

If you are using Convert and your OS has anything to do with German-speaking regions or other interesting Culture settings, then that might be the culprit:

• https://stackoverflow.com/questions/11399439/converting-string-to-double-in-c-sharp#11399479

[fv3 · Accepted solution]

You are right, dont have any German, but on one machine it says the Culture is "en-GB" and the other machine is "nl-NL", so we now added code to make sure its all the same.

In case anyone else has this problem here is the code we use:

System.Windows.Forms.Application.CurrentCulture = new System.Globalization.CultureInfo("nl-NL");

Kind regards,

Fabian

[fv3 · Accepted solution]

You are right, dont have any German, but on one machine it says the Culture is "en-GB" and the other machine is "nl-NL", so we now added code to make sure its all the same.

In case anyone else has this problem here is the code we use:

System.Windows.Forms.Application.CurrentCulture = new System.Globalization.CultureInfo("nl-NL");

Kind regards,

Fabian

[Revitalizer]

Hi,

do not change the application's culture since it affects all other add-ins.

(System.Windows.Forms.Application.CurrentCulture is equivalent to

System.Threading.Thread.CurrentThread.CurrentCulture; both refer to the same object.)

Similarly, setting the CurrentUICulture will interfere with other add-ins too, that can change the UI language of Dynamo, for example.

Revitalizer

[Revitalizer]

Hi,

do not change the application's culture since it affects all other add-ins.

(System.Windows.Forms.Application.CurrentCulture is equivalent to

System.Threading.Thread.CurrentThread.CurrentCulture; both refer to the same object.)

Similarly, setting the CurrentUICulture will interfere with other add-ins too, that can change the UI language of Dynamo, for example.

Revitalizer

[fv3]

Thank you for your response but what can we do to fix this problem? Since its working on one computer but not the other.

We found the cause of this problem, but what would be the best solution?

kind regards,

Fabian

[fv3]

Thank you for your response but what can we do to fix this problem? Since its working on one computer but not the other.

We found the cause of this problem, but what would be the best solution?

kind regards,

Fabian

[RPTHOMAS108]

Use InvariantCulture don't try and change culture of user.

Your main issue is that your stored values are not in InvariantCulture to begin with. We should always store values in this form (which is basically en-US I believe) if they are being used as inputs accross cultures.

So now you would have to know what culture the strings came from to convert to Invariant. We can probably establish the decimal separator of the string (which is all that matters to a double) by looking at what non-number character appears last in a string. e.g. 999.999,99 or 999,999.99

So when you know decimal character you can convert 999.999,99 to 999999.99 by two text replace operations (in right order). Or you can use code similar to in link by specifying what the established decimal character of the input string is.

[RPTHOMAS108]

Use InvariantCulture don't try and change culture of user.

Your main issue is that your stored values are not in InvariantCulture to begin with. We should always store values in this form (which is basically en-US I believe) if they are being used as inputs accross cultures.

So now you would have to know what culture the strings came from to convert to Invariant. We can probably establish the decimal separator of the string (which is all that matters to a double) by looking at what non-number character appears last in a string. e.g. 999.999,99 or 999,999.99

So when you know decimal character you can convert 999.999,99 to 999999.99 by two text replace operations (in right order). Or you can use code similar to in link by specifying what the established decimal character of the input string is.