You found a bug! We've classified it as EXTGWT-3121 . We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #1
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    71
    Vote Rating
    0
    Thomas Fischer is on a distinguished road

      0  

    Default getValue() method of FilterConfig return wrong value for NumericFilter (double)

    getValue() method of FilterConfig return wrong value for NumericFilter (double)


    Hi,

    if i enter in grid header the value "1", i get the value "10.0" in the backend.

    In frontend i typ "1":
    Code:
    NumericFilter<ArticleData, Double> numericBundleFilter = new NumericFilter<ArticleData, Double>(articleDataProperties.bundle(), new DoublePropertyEditor());
            numericBundleFilter.setUpdateBuffer(2000);
            gridFilters.addFilter(numericBundleFilter);
    frontend_screen_shot.jpg

    In backend i get "10.0":
    Code:
    for (FilterConfig myFilterConfig: myFilterPagingLoadConfig.getFilters()){
       String safeTest = myFilterConfig.getValue(); // safeTest is "10.0" ???
    }
    If i enter "10,0" in filter, the backend get's "100.0" if ei read the filter value.

    What's my mistake?

    thank you for reading

    Attached Images

  2. #2
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    71
    Vote Rating
    0
    Thomas Fischer is on a distinguished road

      0  

    Default works ....

    works ....


    This works...

    Code:
    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.


    super parse method.jpg
    Attached Images

  3. #3
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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());

  4. #4
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    71
    Vote Rating
    0
    Thomas Fischer is on a distinguished road

      0  

    Default locale and test

    locale and test


    Code:
    <module rename-to="bibs">
        <inherits name='com.sencha.gxt.ui.GXT'/>
        <inherits name="com.sencha.gxt.chart.Chart"/>
        <inherits name="com.sencha.gxt.theme.base.Base"/>
        
        <inherits name="com.google.gwt.user.User"/>
        <inherits name="com.google.gwt.http.HTTP" />
        
        <inherits name="com.google.gwt.i18n.I18N"/>
        <extend-property name="locale" values="de"/>
        <extend-property name="locale" values="da"/>
        <set-property-fallback name="locale" value="de"/>
        
        <entry-point class="com.spb.online.gxt.client.BIBS"/>
        
        <stylesheet src="reset.css" />
        
        <source path='client'/>
        <source path='shared'/>
    </module>
    result is "10.0" and " #,##0.###"

    test.jpg
    Attached Images

  5. #5
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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:
    Code:
    System.out.println("Current locale name: " + LocaleInfo.getCurrentLocale().getLocaleName());
    Full sample:
    Code:
    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?

  6. #6
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    71
    Vote Rating
    0
    Thomas Fischer is on a distinguished road

      0  

    Default understanding

    understanding


    Result of your code:

    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.



    Thomas Fischer

  7. #7
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.

  8. #8
    Sencha Premium Member
    Join Date
    Apr 2012
    Posts
    71
    Vote Rating
    0
    Thomas Fischer is on a distinguished road

      0  

    Lightbulb use workarround already

    use workarround already


    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.
    Hi Colin.

    I use the workarround, thank you for help.

    Looking forward for next step of migration

  9. #9
    Sencha User
    Join Date
    Jul 2011
    Posts
    126
    Vote Rating
    12
    Andreas Samjeske will become famous soon enough

      0  

    Default


    This is a major show stopper for us! Please, get it fixed asap. Thanx!

  10. #10
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,734
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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.