FWD » Core Development » User Interface

Run the following example in either GUI or ChUI mode:

SESSION:DATE-FORMAT = 'mdy'.
DEFINE VARIABLE dateField AS DATE VIEW-AS FILL-IN NO-UNDO FORMAT '99/99/9999'.
DEFINE FRAME f dateField NO-LABEL.
ENABLE ALL WITH FRAME f.

APPLY '?' TO dateField IN FRAME f.
APPLY '0' TO dateField IN FRAME f.

WAIT-FOR WINDOW-CLOSE OF FRAME f.

In this example, a frame with a date FILL-IN widget is created. The question mark is passed to the FILL-IN using the 4GL APPLY statement to reset the screen value to empty, then a digit character (e.g., 0) is passed in the same manner.

In OE: The screen value becomes 0 / /.
In FWD: The client crashes on sending 0 with StringIndexOutOfBoundsException. Stack trace:

Thread [main] (Suspended (exception StringIndexOutOfBoundsException))
String.substring(int, int) line: 1967
DateFormat$DateBuf.extractComponentText(String, byte) line: 1528
DateFormat$DateBuf.extractDayOrMonth(String, byte) line: 1566
DateFormat$DateBuf.toDate(List<ErrorEntry>) line: 1784
DateFormat$DateBuf.toVar(BaseDataType) line: 1481
FillInGuiImpl(FillIn<O,C>).update(boolean) line: 1164
FillInGuiImpl(FillIn<O,C>).getValue() line: 894
FillInGuiImpl(DataContainer).getChangedValue() line: 90
ThinClient.lambda$97(Object[], Widget) line: 19242
748975217.run() line: not available
ErrorManager.ignoreWorker(Runnable, ErrorManager$WorkArea) line: 4643
ErrorManager.ignore(Runnable) line: 696
ErrorManager.nullErrors(Runnable) line: 713
ThinClient.putWidgetValue(Widget, ScreenBuffer) line: 19242
ThinClient.getScreenBuffer(int, boolean, Set<WidgetId>) line: 19086
ThinClient.getScreenBuffer(int, boolean) line: 19003
ThinClient.apply(int, int, ScreenBuffer[], EventList, boolean) line: 5097

Missing Pre-Input Formatting¶

When a user presses a key, the code in FillIn.processKeyEvent (line 1545) must invoke zapDataPres.input(ch) to update the screen value with delimiters:

if (focused && !isCharacterInGui() &&
    (isZapToBeApplied() ||
     appDataPres == null ||
     appDataPres.isUnknown()))
    ...
    inputRes = zapDataPres.input(ch);

However, for APPLY-driven input (e.g., APPLY '5'), the widget is not focused, so this branch is skipped.

The Fix¶

Remove the focused check from the condition to ensure zapDataPres.input(ch) is invoked regardless of focus state.

Example¶

Consider this example:

SESSION:DATE-FORMAT = 'mdy'.
DEFINE VARIABLE dateField AS DATE VIEW-AS FILL-IN NO-UNDO FORMAT '99/99/9999'.
DEFINE VARIABLE otherField AS CHARACTER.
DEFINE FRAME f otherField dateField NO-LABEL.
ENABLE ALL WITH FRAME f.
ON 'a' ANYWHERE DO:
   APPLY '5' TO dateField IN FRAME f.
   MESSAGE dateField:SCREEN-VALUE IN FRAME f.
END.

WAIT-FOR WINDOW-CLOSE OF FRAME f.

This sets up a frame with two enabled FILL-IN widgets (a character field first, followed by the date field). A trigger on the a key applies '5' to the date FILL-IN and displays its SCREEN-VALUE.

Scenario (GUI Mode)¶

1. Run the example in GUI mode. The initial focus is on the first FILL-IN (character field), leaving the date FILL-IN unfocused. Its initial display shows delimiters (" / /").
2. Press the a key (triggers APPLY '5').

Expected Behavior (OE)¶

• First: 5 / / (displayed and printed).
• Second: 55/ /.
• Third: 55/5 / (etc.).

FWD Behavior (Before Fix)¶

• Printed SCREEN-VALUE is correct (includes delimiters).
• Visible (displayed) value:
  • Does not repaint until window focus changes (e.g., switching windows reveals updates).
  • Lacks delimiters (e.g., shows 5555 instead of 55/55/).

FWD Behavior (After Fix)¶

• Printed SCREEN-VALUE is correct.
• Visible value includes delimiters and repaints properly (e.g., 5 / / on first press).
• Only the first 5 inserts; subsequent presses do not change the visible value.

This post-fix behavior aligns with OE in ChUI mode.

Scenario (ChUI Mode)¶

Run the same example and scenario in ChUI mode.

Expected Behavior (OE)¶

• First a press: 5 / / is displayed and printed.
• Subsequent a presses: the same 5 / / is displayed and printed.

FWD Behavior (After Fix)¶

Matches OE exactly.

Vladimir Tsichevski wrote:

Missing Pre-Input Formatting¶

Fixed in 10894a rev. 16294.

• Only the first 5 inserts; subsequent presses do not change the visible value.

This post-fix behavior aligns with OE in ChUI mode.

This is the remaining difference to fix: implement GUI-specific behavior.

Hynek Cihlar wrote:

Code review 10894a. The changes look good.

I've rebased 10894a to the latest trunk, and added a minor optimization fix. The new revision is 16352.
I've retested the original issue and the #10894-6 issue.
Also I ran Sikuli-based tests. All went well.

Hynek, can you run the ChUI test suite on my behalf?

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Code review 10894a. The changes look good.

I've rebased 10894a to the latest trunk, and added a minor optimization fix. The new revision is 16352.
I've retested the original issue and the #10894-6 issue.
Also I ran Sikuli-based tests. All went well.

Hynek, can you run the ChUI test suite on my behalf?

Running.

I think there is a regression, more details in a PM.

Hynek Cihlar wrote:

I think there is a regression, more details in a PM.

Pressing F4 once acts like pressing it twice.

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

I think there is a regression, more details in a PM.

Pressing F4 once acts like pressing it twice.

Will create a standalone demo.
It requires the partial fix from #11129 to be testable.

Alexandru Lungu wrote:

As ChUI testing passed, can we do a final smoke testing with #9846 customer application? If it succeeds, lets have this 10894a in trunk and then move on with testing of #9846 as notified in #9846-35 (i.e. we must either merge 10894a).

Clarification on dependency between 10894a and 9846c

The fix in 10894a enables fully automatic UI testing with APPLY statements - no user interaction required.
This capability was heavily used during development and verification of 9846c.

However:

• The 9846c fix itself does not depend on 10894a.
• The only complication is that the 10894a fix was cherry-picked into the 9846c branch early - in revision 16331 - before most other 9846c changes.

Consequence when merging 9846c:

• Merging the branch as-is will also bring in the 10894a fix. This is undesirable if we want to keep 10894a separate.

Options before merging 9846c to trunk:

1. Merge 10894a first (recommended): no extra work, clean history
2. Or, in the 9846c branch, forcefully revert rev. 16331: requires additional work (manual conflict resolution, testing)

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

Hynek Cihlar wrote:

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

No testcases other than listed in #10894-1 and #10894-6.

10894a rebased and is now r16414.

The examples in #10894-1 and #10894-6 work as expected.

Hynek Cihlar wrote:

Vladimir, please merge 10894a in trunk.

WIP...

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir, please merge 10894a in trunk.

WIP...

Do you mean there is more work needed?

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir, please merge 10894a in trunk.

WIP...

Do you mean there is more work needed?

No, I mean update trunk, rebase, rebuild the branch and finally merge. This work is in progress...

Vladimir Tsichevski wrote:

No, I mean update trunk, rebase, rebuild the branch and finally merge. This work is in progress...

I see :-)

Hynek Cihlar wrote:

Vladimir, please merge 10894a in trunk.

Committed revision 16414.