David Ayers schrieb:
Actually I get these failures on the trunk also... So I'll need to
investigate... (possibly associated with my locale settings for
decimal
points?)
Indeed this code looks very suspicious:
// if no format specified, use the same default that Cocoa does
if (nil == useFormat)
{
useFormat = negativeNumber ? @"-#,###.##" : @"#,###.##";
}
as does the preexisting code:
- (id) init
{
id o;
_allowsFloats = YES;
_decimalSeparator = '.';
_thousandSeparator = ',';
....
Shouldn't the format honor the values for NSLocaleDecimalSeparator and
NSLocaleGroupingSeparator somehow obtained via NSUserDefaults (or
NSLocale once we have that class)?
Currently in a de_AT.UTF-8 locale these tests fail:
base/NSNumberFormatter/basic.m:
FAIL: default format same as Cocoa
pass([str isEqual: @"1,234.57"], "default format same as Cocoa");
where str = @"1,234."
FAIL: round up for fractional part >0.5
pass([str isEqual: @"1,235"], "round up for fractional part >0.5");
where str = @"1,234"
FAIL: prefix and suffix used properly
pass([str isEqual: @"$1234.56c"], "prefix and suffix used
properly");
where str = @"$1234.c"
FAIL: negativeFormat used for -ve number
pass([str isEqual: @"-$(1234.56)"], "negativeFormat used for -ve
number");
where str = @"-$(1234.)"
FAIL: format string of length 1
pass([str isEqual: @"-1235"], "format string of length 1");
where str = @"-1234"
Please let us know if this can be addressed before the next stable
branch of -base (not the upcoming bug fix release which doesn't
contain
the new code yet) as these formatters will become more interesting for
GDL2 as EOInterface evolves. If you don't have the time, I might try
to
find some.
Cheers,
David
_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev