Problems with decimals in race definitions

[ibboard]

Snowblizz is ​trying to use decimals and encountering problems with the unit points value and the cost multiplier. This could be because of the API or because of the schema.

[ibboard]

Cost multiplier is a custom "nonNegativeDouble" type (takes "double" and sets its bottom limit to 0). Unit points is a custom "nonNegativeNonInfiniteDouble" type (takes a "double" and sets its bottom limit to 0 and its max limit to just below infinity). Problem doesn't appear to be in schema.

[ibboard]

(In r293) Re #185: Problems with decimals in race definitions

• Fix race factory so that it parses unit costs as doubles, not ints

Also:

• Line ending clean-up

[ibboard]

Flagging as "need info" because we need some example data files to see where Snowblizz's probelms are.

[Henri]

screenshot

[Henri]

debugtext

[Henri]

Added debug text and screenshot and 2 example datafiles and system to go with them.

[Henri]

working file

[Henri]

non-working file

[Henri]

system file

[ibboard]

(In r298) Fixes #185: Problems with decimals in race definitions

• Problem fixed with ​ibboard:r103 (XmlTools were using int.parse in double parsing code!)
• Catch and wrap exceptions so that they get caught with a dialog for the user

[Henri]

screenshot

[Henri]

debug text

[Henri]

I am having the same problems with the new beta3 version. Well the GetDouble is used but it fails all the same, see debug text&screen.

[ibboard]

Same data file as you attached earlier? The other thing I'm wondering, given that you're European, is whether there is going to be fun with "decimal point" versus "decimal comma". I know the French use the comma, but I'm not sure which other nations do, and I don't know at the moment what the default .Net behaviour is.

With the attachments, if the screenshot is just the "Unhandled Exception" dialog then the text file should be sufficient as it gives more info than the screenshot :)

[Henri]

Yes the datafiles are the same. I was actually going to mention this whole decimal point vs decimal comma. As I work with Excel a lot that is a common issue one runs into on-line when half the people have a different numbering system. Also having tried both options that would sort of make sense.
Because I tried putting "6,5" which fails already on the XML loading stage, while "6.5" will load but when you try and create the unit it crashes. So the program expects it to be "." but when you finally make a call through .Net it seems it is localized expecting "," and thus fails.

Except for the UK everyone in Europe uses "," way to be different ;-)
​http://en.wikipedia.org/wiki/Decimal_comma

[Henri]

Ok, it was easy to change the system decimal under Vista from "," to "." and that makes it work, so it is definitely an issue with the way regional settings affect the way use Windows decimal separators.

[ibboard]

The fullstop is a terminator, so it makes sense to terminate the whole numbers before you start the decimals. The comma is a splitter in sentences, so it makes sense to split and group numbers. These strange Europeans and their funny numbering :D

I hadn't considered locales for number parsing, but I guess it makes sense. Odd that the XML uses the English separator, although I guess standardising on one thing (which is the American standard) makes sense when you're trying to be inter-operable. Hopefully it should be a quick fix once I'm on my main dev machine.

[ibboard]

Looks like I need to create a NumberFormatInfo, set its NumberDecimalSeparator property to "." and pass that in to the parse.

[ibboard]

Okay, it should be fixed in ​ibboard:r104, which will be included in the next release.

[ibboard]

Set fix not released (field is boolean but doesn't take a default "false" value)

[ibboard]

Mark fix as released even though it isn't to set a value

[ibboard]

Mark fix as not released for unreleased changes

[ibboard]

Mark unreleased fixes as not released

[ibboard]

Released on 31st October as part of v0.1b4

[ibboard]

Mark fix as released under a previous version