Other reasons for EConvertError using StrToFloat () in a Delphi 6 application?
I am having a strange issue that affects at least some of my international users of my Delphi 6 application. Here's the script:
- My program periodically requests status reports from an external device that acts as an HTTP server.
- The device sends the status report as a response document that has series fields separated by a channel character in the format of a name value pair (for example, - field1 = -0.437).
- I split the report line into fields and then again to get each field name and numeric value.
- I am using StrToFloat () to convert the values of a floating point field to string format and assign the result of this function to a Variant .
This works great on most PCs, but some of my international users get EConvertError when I try to use StrToFloat () on numeric values. Here is a concrete example of an error message from my logs:
EConvertError: '-0.685' is not a valid floating point value
As you can see, -0.685 is a valid floating point number, but I am getting an EConvertError exception. I usually expect to see a comma where the decimal point is, or some other locale related issue, but in this case the number seems fine. Also, as far as I know, there is not even a way to set the character set on the external device.
So what subtle nuance about Delphi 6 and international character sets might cause this problem, possibly related to Windows XP / Win7 custom character settings? Please note, I am using standard Delphi 6 " string " in my program, so I don't see how the underlying multi byte problem could be the root cause. Has anyone had this problem and knows what to do about it?
source to share
The expected machine ,
for your decimal point. When encountered .
, an exception is thrown EConvertError
. On a machine expecting ,
as a decimal separator (for example, in most European and South American countries) is -0.685
indeed not a valid floating point value.
Normally I would expect to see a comma where the decimal point is, or some other locale related issue, but in this case the number seems fine.
Your current problem is just an inverted problem. Usually, since your language uses .
as a separator, you are used to seeing problems when using data with ,
. Place yourself in the position of someone from a country that uses it ,
as a separator. For them, they are used to seeing exceptions when using data from .
.
You can fix the problem by normalizing the input to use the same decimal separator as the machine language. On modern Delphi, you can solve the problem by using an overload StrToFloat
that takes a parameter TFormatSettings
and explicitly specifies what .
to use as the decimal separator for this conversion. Unfortunately this object is not available in Delphi 6.
source to share