Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Bugs in AbstractIntegerField
Bugs in AbstractIntegerField [message #1767916] Wed, 12 July 2017 07:02 Go to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 571
Registered: October 2012
Location: Bern, Switzerland
Senior Member
I've stumbled across a couple of bugs in the behaviour of the AbstractIntegerField. (We're using Scout 6.1.0.B009, I haven't testet if a nightly 6.1.0 build or Scout 7.0 behaves differently).

Bug 1: German validation message on minimum or maximum value only
If I use getConfiguredMinValue() and getConfiguredMaxValue() and then enter a value outside this range, the message is correct in German: "Der Wert ist zu klein/gross: Muss zwischen <min> und <max> liegen".

However, if I use only one of the two (getConfiguredMinValue() *or* getConfiguredMaxValue()), the German validation message is incorrect:
"Der Wert ist zu klein: muss grösser als <min> sein" --> correct would be "Der Wert ist zu klein: muss grösser gleich <min> sein".
"Der Wert ist zu gross: muss kleiner als <max> sein" --> correct would be "Der Wert ist zu gross: muss kleiner gleich <max> sein".

The attached code shows this behaviour in the "MinField" (try entering -4) and "MaxField" (try entering 444) fields. I have only tested this with German, I don't know if the English (or other language) texts are correct.

Bug 2: MaxIntegerDigits also crop out of range numbers
If I use getConfiguredMaxValue() and getConfiguredMaxIntegerDigits() and then enter a number that is too large and has more digits than were configured, the number gets cropped to the specified number of digits and an error message is shown about the number being too large. However, the number shown can be smaller than the upper limit, so the error text makes no sense to the user.

To see this demonstrated use the "MinMaxDigit" field in the code below and enter the value "888". This will be cropped to "88" and the error text will be "Der Wert ist zu gross: muss kleiner als 99 sein". However, 88 *is* smaller than "99" so to the user that will be pretty confusing.

The reason for this seems to be that AbstractValueField.setValue() on line 328-330 catches ProcessingExceptions and then calls updateDisplayText(rawValue) which eventually leads to AbstractNumberField.formatValueInternal() being called which then calls getFormatInternal().format(value). However, the format being returned by getFormatInternal() has had the maximum number of digits applied thus cropping any extraneous digits...

I don't see an easy fix for this, but in effect it renders getConfiguredMaxIntegerDigits() pretty useless in conjunction with getConfiguredMaxValue()...

public class TestForm extends AbstractForm {
  @Override
  protected String getConfiguredTitle() {
    return "Integer Field Tests";
  }

  @Override
  public void start() throws ProcessingException {
    startInternal(new NullFormHandler());
  }

  @Order(10.0)
  public class MainBox extends AbstractGroupBox {
    @Order(10.0)
    public class IntegerField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }
    }

    @Order(20.0)
    public class MinField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }

      @Override
      protected Integer getConfiguredMinValue() {
        return 0;
      }
    }

    @Order(30.0)
    public class MaxField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }

      @Override
      protected Integer getConfiguredMaxValue() {
        return 99;
      }
    }

    @Order(40.0)
    public class MinMaxField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }

      @Override
      protected Integer getConfiguredMinValue() {
        return 0;
      }

      @Override
      protected Integer getConfiguredMaxValue() {
        return 99;
      }
    }

    @Order(50.0)
    public class MinMaxDigitField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }

      @Override
      protected Integer getConfiguredMinValue() {
        return 0;
      }

      @Override
      protected Integer getConfiguredMaxValue() {
        return 99;
      }

      @Override
      protected int getConfiguredMaxIntegerDigits() {
        return 2;
      }
    }

    @Order(60.0)
    public class DigitField extends AbstractIntegerField {
      @Override
      protected String getConfiguredLabel() {
        return getClass().getSimpleName();
      }

      @Override
      protected int getConfiguredMaxIntegerDigits() {
        return 2;
      }
    }


    @Order(1000.0)
    public class CloseButton extends AbstractCloseButton {
    }
  }
}

Re: Bugs in AbstractIntegerField [message #1767918 is a reply to message #1767916] Wed, 12 July 2017 07:08 Go to previous messageGo to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 571
Registered: October 2012
Location: Bern, Switzerland
Senior Member
And just to add another detail: If getConfiguredMaxIntegerDigits() ist set (say to 2) without a setting a maximum value: The user can then enter a value that has more digits (say "8888") which is then cropped to the configured digits ("88") when being displayed but getValue() will still return the full number ("8888"). I don't know if this discrepancy between shown value and effective value is intended or not, but I would consider this a bug, too.

My expectation would have been to use the max integer digits for validation instead of for formatting...
Re: Bugs in AbstractIntegerField [message #1771325 is a reply to message #1767918] Thu, 24 August 2017 06:20 Go to previous messageGo to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 571
Registered: October 2012
Location: Bern, Switzerland
Senior Member
/bump because I posted this during holiday season and no reaction has yet been forthcoming :-)
Re: Bugs in AbstractIntegerField [message #1773235 is a reply to message #1771325] Mon, 25 September 2017 08:30 Go to previous messageGo to next message
Beat Schwarzentrub is currently offline Beat SchwarzentrubFriend
Messages: 95
Registered: November 2010
Member
Urs,

Thank you very much for your analysis and the example form.

1. Wrong message

Yes, this validation message is confusing and technically wrong. Apparently, no one noticed this in the past 10 years or so. :-) Can you open a bug for this? It will take a while to fix it, as the same text is used in a number of languages. A similar validation message occurs when both the min and max value are restricted ("value must be between X and Y"). It is also not 100% clear if the lower and upper bound are included in the valid range. Do you have a suggestion on how to improve this message?

Be the way: to quickly fix this in your application, you can just register your own ITextProviderService, provide your own Texts.properties file and re-define the text key.

2. and 3. Min/max number of digits

This is clearly a very confusing behavior. However, is it really necessary to use both properties simultaneously? My suggested quick-fix would be to limit the maximum value or the maximum number of digits. Also, you should always be able to override execValidateValue() and implement your own logic.

The min/max number of digits is implemented using the standard Java DateFormat. Apparently, these properties are only used to format and parse, not validate. Maybe this does not really match Scout's validation cycle, or maybe the JavaDoc is just not clear enough. I cannot give you a definitive answer here, so I suggest, you create a bugzilla for this issue as well.

Regards,
Beat
Re: Bugs in AbstractIntegerField [message #1773304 is a reply to message #1773235] Tue, 26 September 2017 09:42 Go to previous message
Benjamin Schulte is currently offline Benjamin SchulteFriend
Messages: 34
Registered: December 2016
Member
Beat Schwarzentrub wrote on Mon, 25 September 2017 08:30
Urs,
Yes, this validation message is confusing and technically wrong. Apparently, no one noticed this in the past 10 years or so. :-)


I assume it was noticed often, but no one filed a bug report. Me, I must confess I noticed this, laughed and carried on. :D
Previous Topic:Announcement: Eclipse Scout RT Photon will require Java 8
Next Topic:Ludwigsburg, October 23rd: Eclipse Scout User Group Meeting 2017
Goto Forum:
  


Current Time: Mon Sep 24 17:39:52 GMT 2018

Powered by FUDForum. Page generated in 0.01927 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top