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?

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:

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?

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.

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.