Weird regional thing with values and commas?

Hey all,
I have an app which seems to work fine for me (and most users) but rarely on other systems (mostly outside US ones) the comma used for dollar values is considered a dot, cutting off the amount added.

For example, a player wins $5,500 and gets that added to their total. On one test system (in Hungary), they get $5 instead. I would like code that would make this value get added properly regardless of regional differences.

For example, the code I use:

y=val(Replace(ReplaceAll(yy,",",""),"$","")) storsal = y cash = cash + storsal

The variable ‘storsal’ and ‘y’ are dimmed as an integer, and yy is a String. The first line should strip the $ and commas so it gets added as a whole number, I think.
Can someone tell me a foolproof way to do this?

You need to use locale-aware functions. Read up on CDbl etc

So to strip away existing commas and dollar signs and add it to an existing integer value, how would I do this in a fully aware way using CDbl?

Is there any way you can do the math before localizing the values? and then only localize (format) the value when it needs to be displayed to the user?


Markus has pointed the right docs.

a/ Dont store the $
b/ STORE and CONVERT using Val() and STR()
c/ to display, use CSTR() and to read from display back into a double, use CDBL()

A value of 123456.78 is held in a double inside your app
Display it using CSTR()
In America you see 123456.78
In France you might see 123.456,78

If someone types 1.23 on screen in America, they would have typed 1,23 in Hungary
To get both of those to work in your app, use CDBL() and they both turn into 1.23 in a double.
You get the right amount of money in both countries.

Store doubles in a database.
If you want to store the money in a text file, always save it and read it in American format, no matter where you are.

Why? Is that a standard?

Just what I consider sound advice.

If an app stores floats as text in local format, switching locales and sharing the files can cause unexpected bugs.
Been there, bitten by that, solved it this way.
Maybe the OP won’t store values as strings in local format.
But maybe someone else was thinking of doing so.

Yes. As codified by Str() and Val(). You could work around it and create your own standard, but that is the one supplied by Xojo.

Well, I would guess that doing it this way keeps compatibility within your app between different locales.

However the downside to me seems that you loose compatibility with other apps which use the correct locale (importing a table into Excel where the date format is wrong or the thousand separator seems like a receipt for desaster).

In my opinion compatibility with other apps on your computer is MUCH more important then compatibility with other users of your app living in different countrys.

How do Apple and Microsoft deal with this? Store the locale in the file?

It could be a problem if you (for example) create an XML file with a number in it, and used european display style for storage.
XML expects floats to be nnn.nn

You don’t know which country a user of the file will be situated.

I believe they store it in a standard format and then display it according to the user’s locale.

From experience, it is much easier for an app to work with a known format (ie: decimal point as the decimal separator) and just convert input and output to/from the current locale.

It might be easier for the developer, but it doesn’t address the problem of exchanging data with other apps on your computer.

Why doesn’t it? I stated that any input and output should be converted to / from the locale.

What shoudn’t be localised is data that the app uses internally (either in memory or on disk). Doing that just makes your app more complicated with no additional benefit.

It is. Deal with it.

Welcome to planet Earth !

BTW: do you know that 2018 is not the year number for eveybody in this planet ?
Some are in theyr 14xx, some others in their 67xx, etc. And I do not talk about India where many different year numbers exists in the same country.

Because if you are in Europe and save in US format (eg MMDDYY) but want to open the data in another app on your computer (which uses the locale and expects DDMMYY) then you are in trouble.

But if you save in EU format and send it to someone in the US then you again run into problems.

According to Tim the first way is a “standard” which I find doubtful as data exchange with other apps on your computer and other users in your country is far more prevalent than data exchange with users in other countries.

A link would be nice.

And the “deal with it” was uncalled for.

Microsoft Excel… Maybe they’ve done that for Number/Date values in cells - but they certainly haven’t done it for cell Formulas.
So for example a cell with Formula =SUM(A1:A2) results in an error if you open an English document that uses this simple formula with Excel running in German.
There’s no single and correct answer… there is both good and bad from both big and small developers/companies out there.