FWD » Core Development » User Interface

ISSUE

FILL-IN for an integer variable, default format, Swing: if the cursor points to a thousands delimiter, valid input is ignored.
In OE the character is inserted.

ISSUE
FILL-IN for a decimal variable, default format, Swing: if the cursor points to a thousands delimiter, an inserted digit replaces the digit next to the delimiter.
In OE the digit is inserted at the cursor position.

FIXED
Screen value formatting issue:

GUI Swing, both decimal/integer editors:

In OE, a non-unknown value is padded left with spaces, so it is kind of right-aligned.
In FWD: it is not padded and is strictly left-aligned.

I wonder if there are some settings which affect the alignment which I do not know of?

I am remembering that some layout modes (COLON-ALIGNED?, SIDE-LABELS?) might change the alignment of the associated widget. I'm not sure if that is correct or not.

FIXED
Another 2 issues related to the BACKSPACE action in a decimal editor:

1. After I erase the digit 3 in the 12,345.67, the caret position is 2 instead of expected 3.
2. After I erase the digit 6 in the 12,345.67, the screen value is 12,345.07 instead of expected 12,345.70

FIXED
Another issues related to the DELETE action in a decimal editor:

The initial value is always 12,345.67.

1. FIXED After I erase the digit 2, the caret position is 1 instead of expected 2. This is already fixed in 7019a.
2. FIXED After I set cursor after 2 and press DELETE the caret position is 2 instead of 3. This is already fixed in 7019a.
3. FIXED After I set cursor after , and press DELETE the caret position is 2 instead of 3. This is already fixed in 7019a.
4. REJECTED After I set cursor after 5 pressing DELETE has no effect.
5. FIXED After I set cursor after the dot . and press DELETE, the value is "12,345.07" instead of expected "12,345.70". This is already fixed in 7019a.
6. FIXED After I set cursor after the 7 pressing DELETE has no effect.

FIXED
Another issues related to the digit insertion in a decimal editor:

The initial value is always 12,345.67.

1. FIXED After inserting digits at the format positions marked as > (type over the digits 1, 2, 3 or 4 in the initial value) the caret disappears. This is already fixed in 7019a.
2. FIXED Digits can be inserted over the lowest integer part of the format. In FWD digits are not inserted.

Vladimir Tsichevski wrote:

2. Digits can be inserted at the lowest integer part of the format (over the digit 5 in the initial value). In FWD digits are not inserted.

UPD: This issue exists for the >>,>>9.99 format, but does not for the >>,>99.99 format by some reasons.

ISSUE
Yet another issue related to the digit insertion in a decimal editor:

1. The initial value has a single integer digit, which is not zero (for example, 1.00).
2. The caret is at the leftmost position (before the 1 in the example).
3. A digit is typed.

In OE, the digit typed replaces the digit it is over.
In FWD the new digit is inserted before the digit.

UPD: this holds for any number of digits in the integer part: the lowes integer digit is always replaced.

ISSUE
Yet another issue which can be reproduced with 7019.p attached to the #7019 issue.

I enter -890134 into the "Value:" field and click "Set decimal". This sets the decimal editor screen value.
The error appears saying this value cannot be displayed with format displayed, and decimal value is displayed as ??????. This is expected.

Now I delete the last character in the "Value:" field, so the value is now -89013, which is now a correct value. I press "Set decimal" and got the same error referencing the old -890134 value, which is wrong.

I press the "Set decimal" one more time, now no error is displayed, and the value is successfully put to the decimal editor as -89,013.00.

FIXED
Yet another issue: decimal editor: inserting the question mark ? does not reset the editor to unknown state, if the caret is in the rightmost position.

ISSUE
Yet another issue with decimal editor: initially the screen value is filled with spaces (which is incorrect by itself), and if the user positions the caret at the rightmost position (by just clicking inside the widget, for example), the input is impossible (since the caret is in the rightmost position), which is probably very surprising for the user.

ISSUE
Yet another issue with decimal editor:

1. insert an unknown value by typing ?
2. select the ? sign
3. press Delete

Nothing is deleted, which is expected, but in FWD the selection is removed, which is not expected.

ISSUE
Issues related to setting screen value.

Invalid character must not be tolerated, so the following values must cause the "Invalid character in numeric input" error:

1. "a"
2. "a123"
3. "123b"
4. ";123b7".

In FWD all invalid characters are silently filtered out before the string is parsed.

ISSUE
Navigation issue: in OE in GUI mode, the CURSOR-DOWN and CURSOR-UP keys move cursor right and left. In FWD they do not.

FIXED

Ctrl-CursorLeft and Ctrl-CursorRight move caret word left and right.

FIXED

Vladimir Tsichevski wrote:

In OE, a non-unknown value is padded left with spaces, so it is kind of right-aligned.
In FWD: it is not padded and is strictly left-aligned.

UPD: initially, the screen value is right-aligned, as expected, but entering the unknown value by typing the question mark switches the editor to right-aligned mode.

Greg Shah wrote:

I am remembering that some layout modes (COLON-ALIGNED?, SIDE-LABELS?) might change the alignment of the associated widget. I'm not sure if that is correct or not.

The SIDE-LABEL attribute of frame makes FILL-IN left-aligned, the COLON-ALIGNED is used with frame contents widgets only and affect positioning widgets in frame.

Known issues compiled¶

This entry contains all know sub-issues, and will be edited as new sub-issues emerge and existing are fixed.

Screen value formatting.¶

1. The #7794-27 issue.

Input¶

Cursor outside the widget area¶

See #7794-32.

Invalid characters not ignored¶

In a freshly opened FILL-IN pressing an invalid character causes the screen value reset to the zero value. In OE invalid character is ignored.

Valid characters over a thousands delimiter¶

1. FILL-IN for an integer variable, default format, Swing: if the cursor points to a thousands delimiter, valid input is ignored.
   In OE the character is inserted.
2. FILL-IN for a decimal variable, default format, Swing: if the cursor points to a thousands delimiter, an inserted digit replaces the digit next to the delimiter.
   In OE the digit is inserted.
   Another issues related to the digit insertion in a decimal editor:

Disappearing caret¶

(FIXED in 14858)

The initial value is 12,345.67.
After inserting digits at the format positions marked as > (type over the digits 1, 2, 3 or 4 in the initial value) the caret disappears.

Digits are not inserted¶

The initial value is 12,345.67.
Digits can be inserted at the lowest integer part of the format (over the digit 5 in the initial value). In FWD digits are not inserted.
This issue exists for the >>,>>9.99 format, but does not for the >>,>99.99 format by some reasons.

Digits in empty editor are not inserted in the rightmost position¶

Decimal editor: initially the screen value is filled with spaces (which is incorrect by itself), and if the user positions the caret at the rightmost position (by just clicking inside the widget, for example), the input is impossible (since the caret is in the rightmost position), which is probably very surprising for the user.

Digit inserted in wrong position¶

1. The initial value has a single integer digit, which is not zero (for example, 1.00).
2. The caret is at the leftmost position (before the 1 in the example).
3. A digit is typed.

In OE, the digit typed replaces the digit it is over.
In FWD the new digit is inserted before the digit.

Backspace¶

In decimal editor:

1. erase the digit 3 in the 12,345.67, the caret position is 2 instead of expected 3.
2. erase the digit 6 in the 12,345.67, the screen value is 12,345.07 instead of expected 12,345.70

Delete¶

decimal editor, the initial value is 12,345.67.

1. erase the digit 2, the caret position is 1 instead of expected 2. This is already fixed in 7019a.
2. set cursor after 2 and press DELETE the caret position is 2 instead of 3. This is already fixed in 7019a.
3. set cursor after , and press DELETE the caret position is 2 instead of 3. This is already fixed in 7019a.
4. set cursor after 5 pressing DELETE has no effect.
5. set cursor after the dot . and press DELETE, the value is "12,345.07" instead of expected "12,345.70". This is already fixed in 7019a.
6. set cursor after the 7 pressing DELETE has no effect.

Decimal separator¶

Inserting the decimal separator character in the decimal editor does not position the cursor next to the decimal separator (#7794-24).

Region delete¶

1. the difference probably caused by a bug in OE: #7019-92.

Question mark¶

Decimal editor: inserting the question mark ? does not reset the editor to unknown state, if the caret is in the rightmost position. See #7794-13 and #7794-29.

Deleting question mark¶

(FIXED in 14858) decimal editor:

1. insert an unknown value by typing ?
2. select the ? sign
3. press Delete

In OE nothing is deleted, which is expected, but in FWD the selection is removed, which is not expected.
h3. Setting screen value

Fixing a wrong value does not work¶

1. enter -890134 into the "Value:" field and click "Set decimal". This sets the decimal editor screen value.
2. The error appears saying this value cannot be displayed with format displayed, and decimal value is displayed as ??. This is expected.
3. delete the last character in the "Value:" field, so the value is now -89013, which is now a correct value. Press "Set decimal" and got the same error referencing the old -890134 value, which is wrong.
4. press the "Set decimal" one more time, now no error is displayed, and the value is successfully put to the decimal editor as -89,013.00.

Passing invalid values¶

Invalid character must not be tolerated, so the following values must cause the "Invalid character in numeric input" error:

1. "a"
2. "a123"
3. "123b"
4. ";123b7".

In FWD all invalid characters are silently filtered out before the string is parsed.

Alignment¶

1. GUI Swing, both decimal/integer editors:
   1. In OE, a non-unknown value is padded left or right with a space, so right-aligned and left-aligned values always look different.
   2. In FWD: values are not padded.
2. Right-aligned editor becomes left-aligned after an unknown value once was entered to it.

Navigation¶

1. In OE in GUI mode, the CURSOR-DOWN and CURSOR-UP keys move cursor right and left. In FWD they do not.
2. In OE the Ctrl-CursorLeft and Ctrl-CursorRight work like HOME and END. In FWD Swing under Linux they do not.

I am not sure whether this issue exists in FWD under Windows, so this is probably not an issue.

Documentation¶

1. Wrong Javadocs for NumberType.getDecimalSeparatorIndex() (see #7794-23).

May be, this task is not the proper place to report this.

The Javadocs for the return type of NumberType.getDecimalSeparatorIndex() is obviously incorrect (probably, was copy-pasted from some other method):

   /**
    * Parse the numeric format string and return the digit string on
    * the right if it exists.
    *
    * @param    fmt
    *           The format string to parse.  Must be a valid 
    *           Progress-compatible numeric format.
    *
    * @return   The digit text on the right side or null
    *           if no text exists there.
    */
   public static int getDecimalSeparatorIndex(String fmt)
   {      
      return obtainParsed(fmt, null).decimalPoint;
   }

ISSUE
Another issue: inserting the decimal separator character in the decimal editor should position the cursor next to the decimal separator.

In FWD this operation has no visible effect.

FIXED
Alignment-related issue 2: Right-aligned editor becomes left-aligned after an unknown value once was entered to it.

The origin is in the difference between the two NumberBufGui constructors:

      /**
       * Constructs default presentation used for clear operation.
       */
      public NumberBufGui()
      {
         super();
      }

      public NumberBufGui(NumberType var)
      {
         super(var);

         // check if we have right aligned fill-in as front end
         rightAlignedGuiFillIn = editableSource instanceof FillInGuiImpl &&
                                 ((FillInGuiImpl)editableSource).isRightAligned();
      }

The rightAlignedGuiFillIn is not initialized in the first constructor. Copy-pasting the code from the second constructor to the first solves this.

PS: I would prefer to convert rightAlignedGuiFillIn from a field to a method, so we will nether bother about the field proper initialization.

Vladimir Tsichevski wrote:

Alignment-related issue 2: Right-aligned editor becomes left-aligned after an unknown value once was entered to it.

The origin is in the difference between the two NumberBufGui constructors:

[...]

The rightAlignedGuiFillIn is not initialized in the first constructor. Copy-pasting the code from the second constructor to the first solves this.

PS: I would prefer to convert rightAlignedGuiFillIn from a field to a method, so we will nether bother about the field proper initialization.

The 7019c rev. 14979 includes the fix.

ISSUE
Incorrect screen value formatting:

If the format string includes a minus sign character, and the FILL-IN is right-aligned, one character is always reserved for the sign, and space character is displayed there for positive numbers.

In FWD, no space is reserved in case the value is positive.

This issue exists at least in GUI.

ISSUE
Another issue: then a (right-aligned) FILL-IN is just displayed, the screen value must be empty, hence neither cursor movements nor selection are allowed.

In FWD the visible screen value is non-empty and filled with spaces. Cursor movement is allowed, selection is not visible, but is non-empty internally.
Selection deletion results in client crash due to assertion errors.

Vladimir Tsichevski wrote:

Yet another issue: decimal editor: inserting the question mark ? does not reset the editor to unknown state, if the caret is in the rightmost position.

More correct fix replace NumberFormat.java, l. 1169 by:

            screen = Utils.isChUI()
                     ? StringHelper.leftAlignText("?", getScreenWidth())
                     : "?";

This assures the correct values for GUI and ChUI modes both.

FIXED
Yet another issue: clearing FILL-IN in GUI must set the screen value to ?, but in FWD the value is right-padded with spaces.
Padding should occur in ChUI only.

The fix is in #7794-29.

Vladimir Tsichevski wrote:

Yet another issue: decimal editor: inserting the question mark ? does not reset the editor to unknown state, if the caret is in the rightmost position.

The correct fix is using the screen length instead of screen value length.

In theory, both length must always equal, but in current implementation the screen info can be longer, and the extra characters are filled with garbage. This garbage is used in some current code.

ISSUE
In OE pressing BACKSPACE in an initially empty decimal or integer FILL-IN does nothing.
In FWD the same key resets the scree value to the zero.

Trunk rev. 15493.

UPD: this is also true for the DELETE key and any invalid input, like letter a.

DUPLICATE
UPD: this is a duplicate of #7794-27.

After #7794-4 was fixed, the displayed values are right aligned, as expected, but the number of left padding spaces is less by one than expected by the format.

ISSUE
Probably, due to #7794-36, it is possible to enter more digits than the format allows. For example, it is possible to type in the number 12,345,678 into an integer editor with the default ->,>>>,>>9 integer format!

ISSUE
An integer editor issue: in OE, if the format if full, and no more digits can be inserted, it is still possible to overwrite the lowest digit.
In FWD, this this is not possible.

ISSUE

Decimal editor: the cursor is at any position inside the left leading spaces (not at the leftmost position), and BACKSPACE is pressed.

In OE no digits are deleted, and the cursor is moved to the position one character left from the leftmost digit (I assume, as the result of the Delete operation on move cursor left).

In FWD digits are deleted, which is not expected, and the cursor position does not change, which is not expected either.

DUPLICATE

Type in the decimal delimiter character. Regardless of the value and the initial cursor positions, cursor is expected to move to the position after the delimiter.

In FWD this happens only when the cursor points to the delimiter. Otherwise typing in the delimiter has no effect.

UPD: this duplicates #7794-24.

Vladimir Tsichevski wrote:

ISSUE

FILL-IN for an integer variable, default format, Swing: if the cursor points to a thousands delimiter, valid input is ignored.
In OE the character is inserted.

The same issue can be observed in a DECIMAL FILL-IN with a format with no decimal point in it (see #10692-9). So the decimal point in the format is the key.

Vladimir, please make sure to check in any test cases that are still unchecked.