NumericFilter<ArticleData, Double> numericBundleFilter = new NumericFilter<ArticleData, Double>(
articleDataProperties.bundle(),
new DoublePropertyEditor(NumberFormat.getFormat("#####0.###"))
);
This works NOT...
Code:
NumericFilter<ArticleData, Double> numericBundleFilter = new NumericFilter<ArticleData, Double>(
articleDataProperties.bundle(),
new DoublePropertyEditor()
);
If i do not set the NumberFormat in the DoublePropertyEditor class, the default format in the parse method will change the value "1.0" to "10.0" ... can't belive this.
This is very surprising to me - it suggests that GWT's own number format code is parsing "1.0" as the value 10, but either no one else has noticed, or there is something very specific about your setup.
What locale are you using, if any (and does this occur in any other locale)? Do you have any other changes made to your module file beyond basic setup, such as additional replace-with or generate-with rules?
The implication is that that the current decimal format is just wrong, and I'm not sure how that could be. Can you try running this code to verify what output you see?
Code:
String one = "1.0";
Double d = NumberFormat.getDecimalFormat().parse(one);
System.out.println("Parsed as " + d);
System.out.println("Using decimal format " + NumberFormat.getDecimalFormat().getPattern());
It turns out that there is a simple solution here that I was missing - the number format code is doing *exactly* what it should be doing in this case.
Try this: enter "1,0" instead, and see that the result shows up as expected. Additionally, "1.00" will show up as 100. To understand why, we need to add one more line to this test code:
Code:
System.out.println("Decimal separator in current local: " + LocaleInfo.getCurrentLocale().getNumberConstants().decimalSeparator());
This will display a ',' character, since in the selected locale, the period is not used to indicate that decimals are starting. This is standard in many countries around the world such as most of Europe and South America, whereas most of North America uses the '.' character. In both cases, the other character can be used as a separator (though typically for thousands) - for example, 1,000,000.0 is one million in the US, while 1.000.000,0 is one million in Germany. See http://en.wikipedia.org/wiki/Decimal...numeral_system for a complete list.
According to your module declaration, you have Germany set as the default locale, so "1.0" should parse as 10. Add this line to confirm your locale:
String one = "1,00";
Double d = NumberFormat.getDecimalFormat().parse(one);
System.out.println("Current locale name: " + LocaleInfo.getCurrentLocale().getLocaleName());
System.out.println("Decimal separator in current locale: " + LocaleInfo.getCurrentLocale().getNumberConstants().decimalSeparator());
System.out.println("Using decimal format " + NumberFormat.getDecimalFormat().getPattern());
System.out.println(one + " is parsed as " + d);
Back to the original issue, the filters. I'm not sure exactly what is going on there, but will try to reproduce this locally by changing the locale to 'de' and see what happens. I do know that there was a bug in earlier versions of GXT where the wrong number format could be used - what version of GXT are you using?
Current locale name: de
Decimal separator in current locale: ,
Using decimal format #,##0.###
1,00 is parsed as 1.0
Thank you for explaining me my locale-separator-parse problem, i understand.
I'm nearly sure, if i enter in the filter a '1', the frontend make a "1.0" out of it an parse it to "10.0" ... but these workflow i cannot reproduce again now.
gxt version last week: 3.0.3
gxt version now (since 8.7): 3.0.5
my be a proble of the 3.0.3 or a mistake of me. Thank you for help.
Looks like there is still an issue - when you enter "1" into the numeric filter with locale set to de, it ends up rendering as "1.0" instead of "1,0". This won't cause a problem until some change is made to the value, but then it will be parsed wrong. This is a bug in GXT, and I've filed this accordingly.
There is a workaround: instead of just creating a DoublePropertyEditor (or whatever number property editor you are using) with the zero-arg constructor, pass in the appropriate number formatter.
The trick with a fix in GXT for this issue is that we can only set a default formatter based on the type passed in - it might not be perfect, but it will be better than just using the number's own toString code. If you have a desired format to pass in, that should be used instead.
There is a workaround: instead of just creating a DoublePropertyEditor (or whatever number property editor you are using) with the zero-arg constructor, pass in the appropriate number formatter.
Andreas - does the workaround not work for you? Thomas indicated that it solved the issue, and that we just need to build a permenent fix. As the last sentence in my previous post noted, this may not even be something we can uniformly handle perfectly, but will look into it further when we address this, but if the workaround posted does not work, then clearly we don't yet have the full bug report.
getValue() method of FilterConfig return wrong value for NumericFilter (double)
Reply With Quote
result is "10.0" and " #,##0.###"
use workarround already
