Other causes for EConvertError with StrToFloat() in Delphi 6 application?

I'm having a strange problem that is affecting at least some of my international users of my Delphi 6 application. Here's the scenario:

• My program requests status reports periodically from an external device that acts as an HTTP server.
• The device sends back the status report as a response document that has a series fields delimited with the pipe character in name value pair format (e.g. - field1=-0.437).
• I split the report string into the fields and then again to get each field name and numeric value.
• I use StrToFloat() to convert the floating point field values in string format and assign the result of that function to a Variant variable.

This works fine on most PCs, but some of my international users are getting EConvertError's when I try to use StrToFloat() on the numeric values. Here's 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, yet I am getting the EConvertError Exception. Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case. Also, to the best of my knowledge the external device does not even have the option to set the character set.

So what subtle nuance about Delphi 6 and international character sets might be causing this problem, perhaps related to the user's Windows XP/Win7 character settings? Note, I use standard Delphi 6 "string" cast strings throughout my program so I don't see how a multi-byte character set issue could be the root cause. Has anyone had this problem and knows what to do about it?

Your remote user's machine is expecting , for the decimal separator. When it encounters . the EConvertError exception is raised. On a machine which expects , as the decimal separator (e.g. most European and South American countries) -0.685 is indeed not a valid floating point value.

Normally I would expect to see a comma where the decimal point is, or some other locale specific punctuation problem, but the number appears fine in this case.

Your current problem is just the flip-side of the above issue. Normally, because your locale uses . as the separator, you are accustomed to seeing problems when data with , is used instead. Put yourselves in the position of somebody from a country which uses , as a separator. For them, they will be accustomed to seeing exceptions when data with . is used.

You could solve the problem by normalising the input to use the same decimal separator as the the machine locale. On a modern Delphi you could solve the problem by use the StrToFloat overload that receives a TFormatSettings parameter and explicitly specify that . is to be used as the decimal separator for this conversion. Unfortunately that facility is not available in Delphi 6.