FWD » Core Development » User Interface

Run this simplest possible example in GUI mode:

DEFINE VARIABLE l AS LOGICAL NO-UNDO.
DEFINE FRAME f l NO-LABEL.
ENABLE ALL WITH FRAME f.
MESSAGE LENGTH(l:SCREEN-VALUE).
WAIT-FOR WINDOW-CLOSE OF FRAME f.

In this example, a frame with a single FILL-IN of LOGICAL type with the default (yes/no) format is displayed and enabled. Before starting the WAIT-FOR loop, the length of the screen value is reported.

Issue 1: Incorrect initial caret position¶

Initially:

In OE: The screen value is empty (the length reported is 0), and the caret position is 0.

In FWD: The screen value is also empty (the length reported is 0), but the caret position is 1.

Issue 2: Cannot move caret to the rightmost position with Right key¶

1. Type y.
2. The screen value is now yes, and the caret position is 1, as expected.
3. Press the Right key two times to move the caret right.

In OE: The caret moves right from the s, as expected.

In FWD: The caret stops between the e and s.

Note: It is still possible to move the caret to the rightmost position with a mouse click in the FILL-IN area right of yes or with the End key.

Issue 3: Cannot move caret with UP and DOWN keys¶

In OE: The Up key acts the same as the Left key. The Down key acts the same as the Right key.

In FWD: The Up and Down keys do nothing.

Vladimir Tsichevski wrote:

Issue 3: Cannot move caret with UP and DOWN keys¶

In OE: The Up key acts the same as the Left key. The Down key acts the same as the Right key.

In FWD: The Up and Down keys do nothing.

In FWD, UP and DOWN do nothing for any type of FILL -IN (date based, logical, character and so on).

• the caret position is initially wrong also for DECIMAL/INTEGER fill-ins
• the cursor cannot reach the last character from a fill-in with DATETIME/NUMBER format: the same problem like issue 2

Should I treat these issues under this one, or open a new Redmine issue for them?

Delia Mitric wrote:

Other things I've noticed:

• the caret position is initially wrong also for DECIMAL/INTEGER fill-ins
• the cursor cannot reach the last character from a fill-in with DATETIME/NUMBER format: the same problem like issue 2

Should I treat these issues under this one, or open a new Redmine issue for them?

These other issues might be registered already. Otherwise, IMO new Redmine task(s) should be created for them.

Delia Mitric wrote:

Okay, so in this case this can be moved to Review status

Code review and testing 10856a rev. 16322.

Testing

Now UP and Down keys move caret, but do not drop selection, as expected.

Code review

BoolFormat.java: history entry line length exceeds 110 character limit.

Vladimir Tsichevski wrote:

Code review

BoolFormat.java: history entry line length exceeds 110 character limit.

This is not fixed yet.

Also, Ctrl-Up and Ctrl-Down are expected to act similar to Ctrl-Left and Ctrl-Right (as Home and End), but they do not.

All other issues are fixed.

Vladimir Tsichevski wrote:

Vladimir Tsichevski wrote:

Code review

BoolFormat.java: history entry line length exceeds 110 character limit.

This is not fixed yet.

Also, Ctrl-Up and Ctrl-Down are expected to act similar to Ctrl-Left and Ctrl-Right (as Home and End), but they do not.

All other issues are fixed.

• fixed the history entries length
• added support for CTRL-UP, CTRL-DOWN, CTRL-SHIFT-UP, CTRL-SHIFT-DOWN

Committed the new changes to 10856a branch.
Vladimir, please review rev. 16324. Thank you!

Delia Mitric wrote:

issue 1 is solved under #10857.

Please, rebase 10856a to the latest trunk, this will merge the #10857 fix in also.

Rebased 10856a to the latest trunk

Delia Mitric wrote:

Rebased 10856a to the latest trunk

Testing rev. 16367.

Regression found: Up and Down keys in ChUI now work the same as in GUI. In OE CHARACTER mode they must do nothing but move focus by one widget down.

After your change also, in ChUI mode the Up and Down keys are handled in two places in FillIn.processKeyEvent(): in the original key handler, where moveBelowWidget / moveAboveWidget are called in ChUI, next in the Left / Up handler, which I think should not be visited for Up and Down keys in ChUI.

Delia Mitric wrote:

Vladimir Tsichevski wrote:

Delia Mitric wrote:

Rebased 10856a to the latest trunk

Testing rev. 16367.

Regression found: Up and Down keys in ChUI now work the same as in GUI. In OE CHARACTER mode they must do nothing but move focus by one widget down.

After your change also, in ChUI mode the Up and Down keys are handled in two places in FillIn.processKeyEvent(): in the original key handler, where moveBelowWidget / moveAboveWidget are called in ChUI, next in the Left / Up handler, which I think should not be visited for Up and Down keys in ChUI.

This should be fixed in rev. 16368.
Vladimir, please review

Still at rev. 16367.

Vladimir Tsichevski wrote:

Still at rev. 16367.

Sorry, the branch wasn't bound.
Now it should be.

10856a rev. 16368 (testing results + code review)

Code review: the change is good.

Test case – new demo with grid-like layout of 7 FILL-IN widgets of mixed types¶

DEFINE VARIABLE l    AS LOGICAL   NO-UNDO.
DEFINE VARIABLE lr   AS LOGICAL   NO-UNDO.
DEFINE VARIABLE l2   AS LOGICAL   NO-UNDO.
DEFINE VARIABLE l2r  AS LOGICAL   NO-UNDO.
DEFINE VARIABLE c    AS CHARACTER NO-UNDO.
DEFINE VARIABLE l3   AS LOGICAL   NO-UNDO.
DEFINE VARIABLE l3r  AS LOGICAL   NO-UNDO.
DEFINE VARIABLE counter AS INTEGER NO-UNDO.

DEFINE FRAME f
    l lr SKIP
    l2 l2r SKIP
    c SKIP
    l3 l3r
    NO-LABEL.

ENABLE ALL WITH FRAME f.

WAIT-FOR WINDOW-CLOSE OF FRAME f.

Fixed issues¶

• Incorrect initial caret position (FWD placed it at 1 instead of 0)
• Cannot move caret to the rightmost position using Right key
• (for all FILL-IN types): Up / Down keys do nothing in FWD
  In OE: Up acts like Left, Down acts like Right
• Up and Down keys move caret but do not drop selection (now correct)
• BoolFormat.java history entry line length exceeds 110-character limit
• (GUI): Ctrl-Up / Ctrl-Down now behave similarly to Ctrl-Left / Ctrl-Right
• (ChUI): Up / Down keys must not move caret inside the widget; they should only move focus to the widget above/below

Unresolved / unreported¶

1. The caret position is initially wrong also for DECIMAL/INTEGER FILL-IN widgets

Newly discovered issues (ChUI only)¶

Run the test case in CHARACTER mode.

1. Wrong caret position after focus round-trip (Down → Up)¶

Steps:

• Press Down (focus → l2), then Up (focus returns to l)
• Press Right three times (focus → lr, caret at position 0 – correct)
• Press Left (focus returns to l)

Result:

• OE: caret at position 0 (leftmost) – correct
• FWD: caret at position 2 (rightmost) – incorrect

Note: The preliminary Down → Up sequence is required to reproduce the issue. Without it, focus returns to position 0 as expected.

2. Incorrect behaviour of Home and End keys¶

• OE: Home → first widget in tab order, caret = 0
  End → last widget in tab order, caret = 0
• FWD: Home → caret = 0 in current widget
  End → no action

Expected: same as OE (global navigation to first/last widget)

3. Incorrect vertical focus movement (Up / Down) – non-strict alignment¶

Steps:

• Move focus to c FILL-IN (bottom row)
• Move caret so it is visually below l2r (positions ~5–7)
• Press Up

Result:

• OE: focus moves strictly upward to l2r
• FWD: focus moves to l2 (left column), caret = 0 – incorrect

Similar misalignment occurs with Down key.

4. Shift- and/or Ctrl- modifiers must disable navigation keys in ChUI¶

In CHARACTER mode, any combination of Shift + navigation key or Ctrl + navigation key must do nothing (no caret movement, no focus change).
Current FWD behaviour: modifiers are ignored → navigation still occurs.

Vladimir, should we move on to the testing phase, or would you like me to address other issues (listed in #10856-22) related to this one?

Delia Mitric wrote:

Vladimir, should we move on to the testing phase, or would you like me to address other issues (listed in #10856-22) related to this one?

Yes, as long as the other issues from #10856-22 are split into their own separate tasks.

Vladimir Tsichevski wrote:

Delia Mitric wrote:

Vladimir, should we move on to the testing phase, or would you like me to address other issues (listed in #10856-22) related to this one?

Yes, as long as the other issues from #10856-22 are split into their own separate tasks.

Delia, please move the other issues in separate task(s) and start testing.

Created 4 new issues in User Interface project for the ones listed in #10856-22:
#11170 #11171 #11172 #11173

• Tested a customer GUI application (+ ChUI) and Hotel GUI. No regression found.
• Xfer related fill-in tests passed

Delia Mitric wrote:

• Tested a customer GUI application (+ ChUI) and Hotel GUI. No regression found.
• Xfer related fill-in tests passed

Any more testing left?

Hynek Cihlar wrote:

Delia Mitric wrote:

• Tested a customer GUI application (+ ChUI) and Hotel GUI. No regression found.
• Xfer related fill-in tests passed

Any more testing left?

I talked with Razvan about ChUI tests and with Serban for smoke testing on another Customer GUI app.

Vladimir, there are many great findings in the issue. I suppose you had to create multiple tests to cover the changes. Are all of them checked in?

Hynek Cihlar wrote:

Vladimir, there are many great findings in the issue. I suppose you had to create multiple tests to cover the changes. Are all of them checked in?

All findings can be illustrated using the test programs from #10856-1 and #10856-22.
textile

Delia, I reran the ChUI regression tests with the changes from 10856a. Previously there were 28 failing tests, but now they all pass. I guess it was something on my side producing the wrong results. Anyway, everything looks good now. 🎉

Rebased branch 10856a.

Another GUI customer application has been successfully tested.
The testing phase is complete.

It is ready to be merged