problem with StrToFloat
Kathire
I'm having trouble with the StrToFloat function. I use WinXp (English)
to test a my program and I use strToFloat (for converting the string
'1.8' to float )in that. It works without any problem. When the same
program is run in a German Win2000 machine , the program is complaining
the string '1.8' is not a valid string for float conversion. It seems
the German OS is expecting a string 1,8 to refer 1.8. Please let me
know how to solve this problem.
thanks,
Kathire
Anders Isaksson
<kathire-ha...@not-at-yahoo.com> wrote:
*Any* windows computer can use *any* character (almost) as decimal
separator, the English default is '.', the German seems to be ',' (which
is standard also here in Sweden). Check the 'National settings' (?) in
the Control Panel.
Depending on your user, there are different ways to solve the problem:
- You can force them to change their Windows setting to decimal point.
Not a good solution, although I've seen commercial programs that changes
this setting behind the users back!
- You can force your program to use decimal point regardless of the
Windows setting. Look up DecimalSeparator (and UpdateFormatSettings) in
the help. The user may not like this. He will have problems with the
numerical keypad part of his keyboard, as your '.' key will probably be
a ',' key on his, thereby making it difficult to enter numbers quickly.
- You can modify your program to use a decimal point when
reading/writing data files, and using the Windows setting in connection
with user input/ouput.
Where is the string coming from?
If it is input by the user, you should definitely follow the Windows
settings, as that should reflect the user's wishes.
If you are reading/writing a data file, you can temporarily change the
DecimalSeparator to '.' while reading/writing, thus keeping the file in
a consistent form.
If you have a string constant (property?), with a floating point value,
in your code, you should change your code :-)
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
René Allan Larsen
One option is to use the good old functions 'Str' and 'Val' (they predate
Windows and don't know about locale specifications (decimal separator and
so on))). They should however only be used when absolutely necessary and
only when converting data used/stored internally.
Regards, René
Dr John Stockton
nd.public.delphi.language.objectpascal, Kathire <kathire-has-no-
em...@not-at-yahoo.com> posted at Mon, 6 Oct 2003 22:35:34 :-
When you *know* that a number will have a dot as its decimal indicator,
read it with Val. When you *know* that a number must have a dot as its
decimal indicator, write it with Str.
Reserve localisable functions for localisable items.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3 Turnpike 4 ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
Thomas Mueller
Kathire wrote:
In Delphi 7 all StrToXxx and XxxToStr functions have an overloaded version
which takes a record (whose type I don't recall right now) describing the
language settings to use for the conversion. So if you want to use settings
other than the one of the currently logged on user, you can set up this
record appropriately.
But since you brought this up, I have got a much more annoying problem:
A customer is using a program that generates some XML file containting data
I need to parse. Unfortunately this program is using the Windows locale
settings for formatting date/time and floating point values resulting in
unpredictable formats. And since my program might run on a differen
computer with different settings, it must be able to "guess" what format
was used.
I have no way to determine the settings of the source computer other than
what is in the XML and I have no way to add any additional information to
the XML file on the source computer.
Anybody got any thoughts on this? I know that it is nearly impossible to
distinguish between MM/DD/YY and DD/MM/YY format if the day part is <=12.
But there should be some way at least for floats.
regards
twm
Dr John Stockton
news:borland.public.delphi.language.objectpascal, René Allan Larsen
<rene....@spamfilter.dk> posted at Tue, 7 Oct 2003 19:41:16 :-
>
>One option is to use the good old functions 'Str' and 'Val' (they predate
>Windows and don't know about locale specifications (decimal separator and
>so on))). They should however only be used when absolutely necessary and
>only when converting data used/stored internally.
Data can safely enough be localised for display or keying in.
But if the data is to be used elsewhere, the format should not be
influenced by the whims of the computer user. Just think what would
happen if ESA sent NASA data in which Pi was sometimes 3.142 and
sometimes 3,142 .
Never multinationalise if you can internationalise.
Peter Thönell
> But there should be some way at least for floats.
If the string is all you have to go by, then you'll have to examine the
string. So how about first doing a search for , and . ? I know it's not
pretty, but...
Dr John Stockton
.public.delphi.language.objectpascal, Thomas Mueller <ne...@s2h.cx>
posted at Wed, 8 Oct 2003 00:00:39 :-
>A customer is using a program that generates some XML file containting data
>I need to parse. Unfortunately this program is using the Windows locale
>settings for formatting date/time and floating point values resulting in
>unpredictable formats. And since my program might run on a differen
>computer with different settings, it must be able to "guess" what format
>was used.
>
>I have no way to determine the settings of the source computer other than
>what is in the XML and I have no way to add any additional information to
>the XML file on the source computer.
>
>Anybody got any thoughts on this? I know that it is nearly impossible to
>distinguish between MM/DD/YY and DD/MM/YY format if the day part is <=12.
You also need to distinguish YY/MM/DD, and to allow for different
separators. 01/02/03 represents three different dates. However, years
should be YYYY, for the next few millennia.
You may need to distinguish between 12:30 meaning lunch-time, 12:30 a.m.
and possibly 12:30a meaning sleep-time, and maybe 12:30a meaning
lunchtime in (much of) Europe.
>But there should be some way at least for floats.
Text floats can be read by a general routine, perhaps more general than
that supplied, provided that the thousands-separator-problem is removed.
1,234E3 should mean 1234 in a European accent, but could mean 1234000 in
an American one. 1,234.5 and 1.234,5 could be about one or about a
thousand. All that is *really* safe is that a number has at most one
decimal separator.
One solution would be to oblige the customer to include a well-known
data record representing information supplied by you, but in his format:
"You must, for determination of settings, include a first record dated
2001 February 3rd, at six and a half minutes past four in the afternoon,
local time, which orders a plank one and a half metres long."
That determines the date notation and the decimal separator.
This can be tested by your program, and could be built into his.
However, I though that XML was supposed to be capable of complete
unambiguity - if so, maybe your customers are (being thought to be)
using it incorrectly.
<URL:http://www.merlyn.demon.co.uk/js-date4.htm#XML> should interpret a
date in *A* format given by XML, using javascript. You might at least
wish to consider whether you might receive that format.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
René Allan Larsen
>
> Data can safely enough be localised for display or keying in.
>
> But if the data is to be used elsewhere, the format should not be
> influenced by the whims of the computer user. Just think what would
> happen if ESA sent NASA data in which Pi was sometimes 3.142 and
> sometimes 3,142 .
One can argue that file formats and data transfers are used internally (at
least the normal user couldn't care less about them ;) ).
Regards, René
Dr John Stockton
news:borland.public.delphi.language.objectpascal, René Allan Larsen
Elsewhere is not internally.
And, because the average user, as opposed to programmer, is likely to
know nothing of them, they should not be affected by settings controlled
by the user.