Problems with Float representation in XML for German locale

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a tool with e.g. 3.175mm diameter
2. With german settings you actually have to enter 3,175
3. The tool name will still be displayed as "3.175 mm"
4. Storing as default.tooltable gives float values represented with a ","
e.g. 3,175 (see attached file)

What is the expected output? What do you see instead?
All floats are represented with a ",", which is actually the "correct"
representation in a german setting, but those files would not be portable
across different locales.

What version of the product are you using? On what operating system?
HeeksCNC 0.13.0 on Windows XP Professional and Home (German)

Please provide any additional information below.
I guess there is a problem that sometimes the locale setting is used and
sometimes not. Probably sometimes in the libraries being used by
HeeksCAD/HeeksCNC.
I stumbled across similar things with:
- Object coordinates in *.heeks files. Those are actually using the "."
representation, but seem to be read with locale settings, as all float
values are truncated to integers.
- Tool diameters in *.heeks files. Same here. "." representation but
truncated after reading.
- Dialogs sometimes require "." and sometimes "," for floats.

Original issue reported on code.google.com by g.mue...@gmail.com on 18 May 2010 at 8:34

Attachments:

• default.tooltable

[GoogleCodeExporter]

Just wanted to add that there is no problem when setting the Language Settings 
to
English.

Original comment by g.mue...@gmail.com on 18 May 2010 at 8:36

[GoogleCodeExporter]

I'm sorry it has taken so long for me to get to this one.  Hopefully I have 
fixed
this now.  If you still have trouble, please let me know.

Original comment by David.Ni...@gmail.com on 22 May 2010 at 6:24

• Changed state: Fixed

[GoogleCodeExporter]

OK, saving a new default.tooltable works as expected. Float/double values are 
stored
with "." instead of "," now.

Unfortunatly reading XML data with float/double values still does not work. I 
guess
the underlying float/double parser tries to use the language setting and 
expects a
"," for German localization.

I set up an development environment under Linux and could reproduce the problem.
I tried to debug a bit, but could not find the actual place where the 
float/double
values are parsed.

Bye
Guido

Original comment by g.mue...@gmail.com on 22 May 2010 at 10:26

[GoogleCodeExporter]

Guido,
  the change I thought I made was to force the XML interpretation to use the
machine's locale settings.  It used to force the settings to the 'English' 
version
(dots as decimal points).

  I have just re-read your original posting and now I'm quite confused.  Are you
saying that, with this latest change, the default.tooltable still uses the dot 
(.) as
the decimal point.  Further, are you saying that you want it to use dot (.) 
instead
of comma (,) even though the locale settings indicate a comma should be used?

  I suspect you are saying that you just want it to be consistent.  I would have
thought that the use of the locale settings is what we want in most 
circumstances.

  I did fix a problem recently where a machine configured with German locale settings
was failing when reading in a font file that used dots in its floating point 
numbers.
 In this case, I added an extra step that checked the local machine's configuration
and allowed dots to be used for floating points.  I could add this check 
throughout
the code but I suspect it would add even more trouble.  There are cases where 
we ask
the code to read in a floating point number from a character string and tell us 
where
it stopped. (strtod()) By adding an option to handle either comma or dot to all 
cases
might introduce errors.

  Thanks
  David Nicholls

Original comment by David.Ni...@gmail.com on 26 May 2010 at 1:54

[GoogleCodeExporter]

Sorry, I should have changed it back from 'fixed' to 'accepted' status.

Original comment by David.Ni...@gmail.com on 26 May 2010 at 1:55

• Changed state: Accepted

[GoogleCodeExporter]

David,

yes, I also was puzzled when I had a look at your code changes and how it was 
before.
It looked before as what I would have expected how it should work (Reading and
writing with English/neutral locale settings.

I confirm that I have compiled your latest tinyxml code (svn:1163) without the
"ss.imbue(std::locale("C"));", but still (.)s are saved instead of (,), but on
reading only (,) seems to be expected, because everything after the (.) is 
discarded.

Strangely enough, reading geometry data from a *.heeks file works with different
locale settings. It always reads and writes (.). But, when a tooltable is 
included,
this one is not read correctly. This leads me to the conclusion that the 
tooltable is
somehow read differently.

Another observation: I added some debug output to 
TiXmlAttribute::DoubleValue(). This
is actually triggered for geometric data, but not for the tooltable (neither
standalone in default.tooltable nor embedded in a *.heeks file)

The critical data is in the params tags in the tooltable definitions. Are they
handled differently?
Aaaaahhh, writing this down actually helps finding the problem: The params seem 
to be
read in CCuttingToolParams::ReadParametersFromXMLElement(). It just uses atof() 
and
would need something to set the locale to neutral/English.

As a general remark: Yes, I would prefer to have all XML files to be 
independant of
the locale settings. This means, storing all doubles as (.). Otherwise you 
would run
into problems when exchanging *.heeks files across different locales.

Puuuh, that was lengthly!

Hope this helps,
Guido

Original comment by g.mue...@gmail.com on 26 May 2010 at 7:30

[GoogleCodeExporter]

Guido,

  thanks for doing all the hard work for me.  I have run through the code and changed
the atof() calls that relate to XML into calls that use the tinyxml class 
methods so
that it's all more consistent.

  I will change the code back to using the std::locale("C") so that the XML data is
consistently written no matter what the machine's locale settings are.

  I won't have this stuff committed until I get home tonight (it's lunch time for me
now).  I will let you know when it's done.

  Thanks
  David

Original comment by David.Ni...@gmail.com on 27 May 2010 at 3:37

[GoogleCodeExporter]

OK, try this now.

Original comment by David.Ni...@gmail.com on 27 May 2010 at 8:26

[GoogleCodeExporter]

Dan,

Relax! No need to hurry! 8-)

I just did a quick check and it works as expected. Hooray!
Thanks for your quick response and fix. Great work!

You can close this issue now.

Guido

Original comment by g.mue...@gmail.com on 27 May 2010 at 8:11

[GoogleCodeExporter]

Original comment by David.Ni...@gmail.com on 27 May 2010 at 9:23

• Changed state: Fixed