[RESOLVED] Better way to get locale's decimal character?

[DigiRev]

I know I've seen this posted several times on the forum but searching didn't bring up anything relevant.

I want to know how to get the decimal character for the current locale/regional settings.

Example: Most use a standard period as decimal, while other countries use a comma.

Right now, I just did a small "hack" and I'm not sure how reliable it will be:

MsgBox Mid$(CStr(Format(0, "fixed")), 2, 1)

[Lightning]

You could do this:

dim a as currency
dim b as string 
a = 1.2
b = a
msgbox(mid(a,2,1))

But of course the "best" way would be to read out the registry

[edhanz]

i test it first like:

Text1.Text = 5 / 2

result can be 2,5 or 2.5 depend on regional settings.
i dont know, but is it what you're looking for?

[westconn1]

i guess the real question is, why you should need to know?
your code should be able to work correctly for either

[Lightning]

The problem is that 1.000 could represent 1 (if . is the decimal separator) or 1000 (of , is the decimal separator and . is the thousand separator)

[Milk]

I agree with westconn1. There should never be any need to know what the local separator is. All the functions required to handle numerical strings correctly to locale are available in VB. It is also naive to assume the the separator will be either dot or comma, it can be anything the user wants it to be.

In the scenario where a system of one locale passes numbers to a system of a differing locale, these numbers should not be sent as strings. Or at least if they have to be strings they should be formatted in a particular way.

[LaVolpe]

Agree with the last few posters.
To convert string to regional settings number system, use vb conversion functions like CLng, CDbl, CCur, etc. Do not use Val() as it is not regional aware.

[DigiRev]

I was doing a check in the _KeyPress() event for a decimal character, so it only allows them to enter a decimal if there isn't already one there. Easy enough, assuming I know the correct decimal character.

[Milk]

IsNumeric() will return false if more than one decimal separator is present (regardless of what that separator is)

The KeyPress event does not enable policing of right click menu pasted data. It's common to do some further validation in say the Change or Validate event, which in turn might be a better place to assess the validity of the number as a whole.

I still don't think you need to know what the separator is.

[LaVolpe]

Maybe post 2 or 3 would suit you. Of course if you cache this character on form load, if someone changes their regional settings while your app is loaded, it would cause you problems. Then again, you can always calculate it on the focus event of the textbox.

But Milk's point is a very good one; pasting is something to deal with.

[DigiRev]

2 and 3 are basically what mine does but with more code.

But I will probably use the IsNumeric() function.

[Milk]

This may not apply to you Dan(?) but speaking as someone who obsesses a little too much over the efficiency of code, dealing with user keyboard input is not an area to worry about. Really awful inefficient keyboard policing will probably still run much faster than anyone can possibly type.

[dilettante]

Just use one of the variations on Mid$(CStr(1.1), 2, 1) since that is probably as quick and reliable as you'll get.


Another important reason to have this information is for formatting values for transmission between computers. If you serialize data to Strings (or even XML) you can't rely on CStr() and CCur()/Cdbl()/CSng() alone because these will use the local settings. This means a message sent from the U.K. to France would be misinterpreted, since the former uses "." and the latter ",".

While it might seem a bit Anglo-centric, the common medium of exchange is to use "." so you need to always perform this conversion. Thus most serializer/parsers contain something along the lines of:

    Private Function UnivCCur(ByVal Value)
        UnivCCur = CCur(Replace(Value, ".", DecimalPt))
    End Function

    Private Function UnivCDbl(ByVal Value)
        UnivCDbl = CDbl(Replace(Value, ".", DecimalPt))
    End Function

    Private Function UnivCSng(ByVal Value)
        UnivCSng = CSng(Replace(Value, ".", DecimalPt))
    End Function

    Private Function UnivCStr(ByVal Value)
        UnivCStr = Replace(CStr(Value), DecimalPt, ".")
    End Function

Where DecimalPt is set during the Class_Initialize event.

As written the code above works in a VB, VBA, or VBScript class. For VB/VBA you might want stronger typing than the default Variants, but the logic is the same.


Yet another reason is for formatting CSV data. Not only do you need to worry about "," as decimal point, in such a locale the field delimiter is usually ";" instead of "," as well.

[dilettante]

You can also detect a locale change by using the VB6 SysInfo control. Whenever the SettingChanged event occurs, refresh your DecimalPt (or equivalent). If you're picky you can check the event's section parameter for the value "intl" which means the locale changed.