Re: Comma vs. Decimal

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

No, you're not going insane !! even if BG is doing his best to acchive that.

This is a typical W2K/XP behaviour.

"dont ask the user, just make some changes and see whats happen"

After I got tired keeping an eye on those auto changes I stoped trying to
debug it that way, I compiled it, took another machine, change the locals
setting, incl keyboard, and run it there for testings/debugging

Rick's input is really looking good, have a look at them.

Do you store your decimal values as strings or as decimal values?
In a database or in what?, what type of datatype?

Reading from a database and displaying on screen cannot be a problem, you'll
of course get the decimal placeholder stated by the locals but that should be
fine.

Just focus on the moment when interpret a string into a decimal value, use
ricks input to make sure you can turn it into a decimal suitable variable.


Kjell



"Lenny Abbey" wrote:

This is getting crazy.

I am using Win 2K. I set my locale to "German (Germany)". Fine. A little
icon appears in the system tray saying "DE". Fine. I launch the IDE to debug
my program. Not fine. The little icon now reads "EN". I am back in "English
(United States)" locale. But the program is still throwing (seemingly)
random commas at me. When I close the IDE down, the icon says I am back in
DE mode.

I get the same locale switching when I run the compiled program.

Am I going insane? The "help" file doesn't mention this strange behavior.

Lenny




"Kjell" <Kjell@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C1E3BAE8-8743-4A11-B206-F2138F4ABEE2@xxxxxxxxxxxxxxxx
I know what you're going through Lenny, I've been down that road my self,
it's not fun.

I'll never forgive BG for allowing all countrys having their own locals in
Windows.
I can learn to use the USA formats much quicker than trying to figure out
all traps how to handle decimal and dates formats correctly the BG way.



but, here are what I learned from my fight.

Presenting decimal values on screen (taken from a database for example) is
never a problem, just assign the decimal value to a textbox or listitem
etc..

You have two major traps to solve.

Decimal values taken from a txt file and decimal values coming from users
input.

You must figure out which decimal character is correct on the users
machine.

You cannot trust the user for using the right character, in europe
distances
are short, a visitor from another country can be in front of the pc.

I know that this info can probably be picked up in the registry somewhere,
but I have a trick that will tell you quickly which decimal character to
use.

Put a hidden textbox (visible=false) on the form that monitors the file
reading or the input from the user.
put this in the load event
Text1.text = 1/2
(maybe the 'by the book format' should be:
Text1.Text = Format(1 / 2, "0.0")
but VB6 is very forgiving converting values)

You can then check the second character to see which character is the
correct decimal placeholder, and replace whatever character is coming in
from
file or user inputs with this. :-)

If your values are high you might hit the next trap, thousand seperator
character, some countrys uses the comma or a dot for this and the other as
a
decimal placeholder at the same time.

If this is the case, or can be the case you better check the "string" if
both characters are present, save the location of the right most of them,
replace both with "" and put back the correct character for decimal
placeholder only.

After that you're safe to pass/convert it to a double variable for
example.

OBSERVE, I did not mention MS-Excel here, it's even worse.

PS
I haven't checked Larry's and Rick's suggested multi purpose functions
yet,
they might do the job where ever they are used whatever the users trying
to
type in.
but I'm carefull when betting on this subject, I've burned my fingers so
many times already.


Kjell


"Lenny Abbey" wrote:

My program is for the collection of astronomical data. It takes date and
time (input in 6 text boxes), and some other numeric data, which can be
treated as strings, and formats them into a delimited data record. The
file
mad up of these records is then uploaded to a distant server via the
internet.

The first thing the program does is to convert the data and time into
Julian
Date (a long number with many decimal places). In Germany, for instance,
the
decimal place in the JD field comes out as a comma, which you would
expect.
I need to override the comma with a decimal. But...if the user enters
the JD
directly, he is forced by his locale setting to use the comma, which I
want
to get rid of.

For some strange reason, resetting the German computer to the USA locale
is
not a very good solution. It corrects some things (allowing decimals in
input boxes) while producing new errors of its own (results of
calculations). I think that Windows' locale changing applet doesn't do a
very good job.

If I could do a "locale-lobotomy" on the user's computer things might be
OK.
I'm even getting hate mail as a result of this problem.

Lenny









"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:%23i0KYX68HHA.1936@xxxxxxxxxxxxxxxxxxxxxxx
Which way around are you problems Lenny? What sort of problems are
your
users getting?

Windows cannot really override locale settings for a specific program,
or
a
thread within a program. Any attempt to change them programmatically
is
likely to affect more than what you want, and cause more complains
because
it's deliberately going against a user's own preferences/settings.

As an aside, here's an interesting blog from a well-known person who
knows
a
lot about this stuff:
http://blogs.msdn.com/michkap/archive/2005/08/22/454360.aspx

Tony Proctor

"Lenny Abbey" <labbey@xxxxxxxxxxxxxx> wrote in message
news:13e6gi3cd40b28b@xxxxxxxxxxxxxxxxxxxxx
Is there a way to temporarily force the computer to override the
decimal
and
thousands separator for locales outside the US?

My users are giving me fits over the problems I am having with this.

Thanks,

Lenny










.

Relevant Pages

  • Re: Reading Unicode Strings from File
    ... > CHAR Unicode character. ... > There is absolutely no need for these strings to be in unicode format ... program you will be limited to the locale dependant codepage. ...
    (comp.lang.c)
  • Re: egrep oddity
    ... In the en_US.UTF-8 locale what would traditionally have ... The commands behave as expected on a different GNU/Linux system. ... The character collation sequence affects almost everything on the ... I have no idea how that would interact with all character sets. ...
    (Debian-User)
  • Re: Comma vs. Decimal
    ... I set my locale to "German ". ... The little icon now reads "EN". ... I can learn to use the USA formats much quicker than trying to figure out ... You must figure out which decimal character is correct on the users ...
    (microsoft.public.vb.general.discussion)
  • Re: FAQ 6.7 How can I make "w" match national character sets?
    ... Put "use locale;" in your script. ... How can I make "\w" match national character sets? ... against a character string. ... Even if it is a bug what ...
    (comp.lang.perl.misc)
  • tr A-Z a-z in locales other than C
    ... A few years ago, when locale support was added to the tr utility, ... changed to use the collation order instead of the character code order. ... simplified more as the flags for octal escapes are no longer needed. ...
    (freebsd-hackers)