There are likely good reasons why it has been designed this way, but this is an easy trap for many … Wel, RTFM is always the answer, isn’t it? @DerkJ Thank you very much for your help and your time, very much appreciated!
Var loc as new Locale("de_DE")
Var percentage As Double = Double.Parse( items(3).left(items(3).Length - 1), loc )
messageBox(percentage.ToString( loc ))
@DerkJ It seems this is closing the loop of my original question:
double.parse
which I wasn’t aware of seems to be this localization I was looking for. Now it is working, but it still seems or at least “feels” wrong - but perhaps this is just the path you have to follow if you are unlucky like me and you have to deal with non US formats :-).
Thanks again, in one millions years I found not have found this hint.
I know it can be hard, but these outputs are differently which should NOT happen if the locale is RAW (unified the same) or the input value must be different? Or some of the xojo functions handle it differently on different platforms. Which i think should NOT happen…
Anyway as long as you can move on, that’s what’s counting.
I fully agree, most likely because Xojo dev is not running themselves into these issues, at least not very often? I would assume that a simple toDouble will do what it is supposed to do or raise an exception. How “val” is working in this particular example doesn’t make much sense to me either.
On top of that I’m setting: Session.LanguageCode = "de-DE"
So I would assume that any browser interference will be overwritten as well. Perhaps @Greg_O_Lone will tell us that we overlooked something or will find a bug. It just looks strange to me.
For percentage it is not dramatic as you see the problem instantly, different stories for currencies for instance not to speak of any mathematical calculations …
First, Setting the browser LanguageCode doesn’t affect Xojo code except for what localized constants are used.
Next, you mentioned that the locale on the server is set to en-US-UTF8, but I didn’t see what your local machine is set to. If it’s de-DE then everything here makes sense.
The locale of the machine that your code is running on makes all the difference in the world as to how ToDouble and ToString (or Cdbl and Format) work. They both take the computer’s locale into account as to how a number should be formatted for conversion. That means that the thousands and decimal separator must match what the locale on the system where your app is running says it should be.
My suggestion is that you create a Locale object from the browser’s LanguageCode and use that for conversions. You’ll have a better chance of getting the correct conversion for whatever the end-user has their system set to and is using themselves.
Does someone else have a Linux machine at his hands to test? It seems to me that I can change my Ubuntu locale on the remote to en_US.UTF8 with no impact on the code whatsoever. But I want to avoid wasting your time with some crazy configuration error on my machine (though, I don’t think there is a major problem).
It’s not shifting. The problem is that ToDouble doesn’t recognize the comma as a decimal separator and strips it when the system is set that way.
As an example, on a US system, a string formatted as “1,234.56” becomes a double with a value of 1234.56. Thousand separators are stripped. If your string had been “11,555”, the double would have given you 11555.
@Greg_O_Lone this makes perfectly sense, that’s why I asked about “localization for double” in my initial questions. Wrapping things up, am I right to assume that if you have settings where the decimal separator is not a period, you have to work with a local in the following way:
Var yourString As String = "10.000,45"
Var loc as new Locale("de_DE")
Var yourDouble As Double = Double.Parse( yourString, loc )
That’s exactly what I assumed but which doesn’t seem to work.
They were, I did a reboot of the server.
Where I am not confident is that the locale I’m seeing in the bash after SSH-ing into the server is really the global “locale”. The below settings is what I’m seeing in the bash, after being SSHed into that server. The WebApp runs however as a services, perhaps that’s the issue, running under a system user with a different locale?
I assume you’re getting those values using “env”. Have you tried having your app run that command using a shell? You might also try running “whoami” to find out what user you are.