FWD » Core Development » User Interface

Problem origin

In FWD, the processing of keyboard events for FILL-IN widgets depends on whether the containing window is focused. When the window lacks focus, the FILL-IN caret is forcibly set to the leftmost or rightmost position, based on the widget’s alignment. This adjustment occurs both before and after event processing, overriding any caret position changes made during the event. Consequently, programmatic inputs, such as those sent via APPLY before the WAIT-FOR loop (when the window is unfocused), lose their intended caret positioning.

This behavior aligns with OE character mode but is incorrect for GUI mode, where caret positions should persist as set by event processing.

The problematic code, located in FillIn (line 1548), has existed since revision 10115 (committed by Constantin in pre-GUI era) and was not updated for GUI mode.

                  // apply char without moving cursor
                  if (isRightAlignedInt())
                     config.appDataPres.moveCursorEnd();
                  else
                     config.appDataPres.moveCursorBegin();
                  ...               
                  boolean input = config.appDataPres.input(ch);
                  ...
                  if (isRightAlignedInt())
                     config.appDataPres.moveCursorEnd();
                  else
                     config.appDataPres.moveCursorBegin();               

The issue stems from FWD’s event handling for FILL-IN widgets:

1. In GUI mode, FillInGuiImpl’s processKeyEvent method performs pre- and post-processing around the superclass FillIn’s processKeyEvent method, providing flexibility for GUI-specific behavior.
2. In ChUI mode, only FillIn’s processKeyEvent method is used, handling both ChUI and GUI logic. This makes the method overly complex and prone to errors, as it lacks mode-specific separation.
3. The ChUI-specific FillInImpl does not override processKeyEvent, leaving no dedicated place for ChUI-only logic.

Proposed Solution

To resolve this, introduce an overridden processKeyEvent method in FillInImpl for ChUI-specific logic, moving the caret adjustment code there. This ensures:

1. FillIn’s processKeyEvent handles shared logic only.
2. FillInImpl’s processKeyEvent manages ChUI-specific behavior, like caret positioning when the window is unfocused.
3. FillInGuiImpl continues to handle GUI-specific pre- and post-processing.

Note: The proposed fix was also implemented while resolving #9913, overriding processKeyEvent in FillInImpl to handle ChUI-specific logic.

The issue was fixed in 9929a, revision 15877. Now, printable keyboard characters sent using the APPLY are processed "naturally" in GUI, while the quirk described in #9929-2 persists in ChUI mode, matching OE behavior.

Code review 9929a.

The changes look OK to me. Kudos for keeping the changes to the bare minimum :-).

Please go ahead with regression testing, also include ChUI regression tests.

You can merge to trunk now.

Vladimir Tsichevski wrote:

Can this be closed?

Yes.