Isnumeric Europe vs USA

Getting Started
1

I have an input box that accepts numbers. If your decimal separator is a comma, the following happens
1.5 is entered into a textfield
isnumeric(textfieldName.text) returns true
Cdbl(textfieldName.text) returns 15

If your decimal separator is a period, the following happens
1,5 is entered into a textfield
isnumeric(textfieldName.text) returns true
Cdbl(textfieldName.text) returns 15

How do I ensure only valid numbers are entered?

2

TextChange

me.Text = me.Text.Replace(",", ".")
3

But I don’t always want to change the decimal separator. Only if the wrong decimal separator is used. Why doesn’t isnumeric recognize the text as non-numeric if the incorrect decimal separator is used?

4

I think IsNumeric and CDbl do not take “thousands separators” into account, it removes them before testing or converting. But only the “thousands separator” of the current country settings:
Germany: nnn.nnn.nnn,nn –> the dots are removed
Switzerland: nnn’nnn’nnn.nn –> the apostrophes are removed
US: nnn,nnn,nnn.nn –> the commas are removed

5 
FUNCTION myIsNumeric(s as string) as boolean
dim decSep as string=removeall(format("3333","#,###"),"3") // in US returns comma
dim decPt as string=removeall(format(3.3,"#.#","3") // in US returns period
return isNumeric(replaceall(replaceAll(s,decSep,""),decPt,".")
END FUNCTION

Doe that work? (untested)… if should determine the Localized Thousand Sep and Decimal Point characters, then remove the Thousand Sep, and change the Fractional Sep to a period…

6

Why not use Locale?

http://developer.xojo.com/xojo-core-locale

7

Absolutely. That’s a case for the Xojo framework. Use the Double.Parse or Double.fromText method together with the current locale and you don’t have to worry about dots and commas anymore.

8

There are two issues here:

  1. Determining whether a string of characters is a valid representation of a number.
  2. Converting that string of characters into a number.

IsNumeric is supposed to do the first.

Parse, Val and Cdbl will do the second, but there is no guarantee that they will return what was intended if the user made a mistake or used the wrong decimal separator.

You really have to use both, and they both have to work correctly for the user’s location.

9

Use two input boxes, separated by a label that shows the correct separator your app retrieved from locale. The input boxes accept only numbers, nothing else. Your app handles both input accordingly.

10

Doesn’t the textfield.mask limit input to the correct seperator? http://documentation.xojo.com/index.php/TextEdit.Mask

11

I was fooling around recently and was in trouble "cause of this…”. After some minutes I left Xojo and forget about it…

12

No. Unless you can come up with a location-aware mask.

13

So the docs are incorrect? [quote]Decimal placeholder.
The decimal placeholder that is actually used is specified in the user’s International settings[/quote]

I am only asking because I have never been exposed to this issue and would like clarification.

14

all english speaking native users here can’t figure the problems we have for non english and localisation…
xojo is an american company, and they can’t really test all sort of localisation problems we encounter everyday …

I ended up making my own method(s) for converting numbers french formatted. it’s quite easy.
I’m now faced with an english customer and I’m pretty sure my methods will not work for him.
same problem with dates.

15

Well I guess we can only hope that as Xojo rolls out the new framework we’ll be able to specify a mask that is locale aware (again although the docs sort of imply this for the classic framework).

16

In some parts of the world this implies cheating on your partner - get your locale right :slight_smile:

17

Thanks for all the help. I just added a check for the local decimal separator and all is well. This board is fantastic!