FWD » Core Development » User Interface

In OE, multiple FILL-IN widgets of CHARACTER type can be grouped, allowing text entered into one FILL-IN to wrap into the next in the group when it exceeds the allotted space.

This issue addresses problems in FWD's implementation of this feature.

To illustrate the discrepancies, consider the following example in GUI mode:

DEFINE VARIABLE txt1 AS CHARACTER NO-UNDO FORMAT "X(4)".
DEFINE VARIABLE txt2 AS CHARACTER NO-UNDO FORMAT "X(4)".
SET TEXT(txt1 txt2).
DEFINE FRAME f txt1 txt2.
ENABLE ALL WITH FRAME f.

WAIT-FOR CLOSE OF FRAME f.

Issue 1¶

1. Enter a single printable character, such as a, into the first txt1.
2. Move the caret to position 0.
3. Begin typing spaces before the a.

In OE, upon entering the 4th space, the a shifts to txt2, the focus remains in txt1, and the caret moves to position 0.
In FWD, upon entering the 4th space, the a is removed, the focus shifts to txt2, and the caret moves to position 4.

Issue 2¶

1. Input four printable characters, such as abcd, into the first txt1.
2. Use the mouse to set focus to txt2.
3. Press Backspace.

In OE, the focus returns to txt1, the last character (d) is deleted, resulting in a displayed value of abc, and the caret moves to position 3.
In FWD, the focus returns to txt1 (as expected), but the first character (a) is deleted, resulting in a displayed value of bcd, and the caret moves to position 0.

Ionut-Mihai Simioniuc wrote:

Vladimir, could you provide some information about the area where the issue might occur?

Grouped FILL-IN widgets are used within our ChUI testing framework. It appears they were employed prior to the availability of the EDITOR widget in OE.

Grouped FILL-IN widgets are used within our ChUI testing framework. It appears they were employed prior to the availability of the EDITOR widget in OE.

Hmm, I'm looking for methods, classes, or any information related to the communication between text1 and text2 through SET TEXT. I tried inspecting processKeyEvent from FillIn but nothing helpful until now. I believe I need to identify the exact location where text1, or something else, sends a value to text2, or triggers the update.

Thank you!

Ionut, look into GenericFrame.setWorker, GenericFrame.promptForWorker from the server and ThinClient.promptFor on the client, on the client especially there are some focus related calls:

         if (focus != null)
         {
            highlight(focus, false);
         }

         // if in trigger nesting mode, save previous focus
         if (triggerNesting > 0)
         {
            pendingFocus = focus;
         }

         BufferSizeManager.getInstance().notifyBlockingOperation(BlockingOperation.PROMPT_FOR);

         // old focus has to be undefined
         wnd.setFocus(null);

         result = waitFor(el, focusWidgetId, millis, sb, BlockingOperation.PROMPT_FOR, true, windowId);

this is for sure the area with an issue.

Ionut-Mihai Simioniuc wrote:

Grouped FILL-IN widgets are used within our ChUI testing framework. It appears they were employed prior to the availability of the EDITOR widget in OE.

Hmm, I'm looking for methods, classes, or any information related to the communication between text1 and text2 through SET TEXT. I tried inspecting processKeyEvent from FillIn but nothing helpful until now. I believe I need to identify the exact location where text1, or something else, sends a value to text2, or triggers the update.

Thank you!

The SET TEXT statement groups two FILL-IN widgets together.
The boolean FillIn.groupMode serves as a flag indicating whether a FILL-IN belongs to a group.
The private boolean FillIn.refill(boolean insert, int key) method is responsible for propagating changes within a FILL-IN to subsequent group widgets.

Vladimir, could you give me more information about this override parameter? And the logic behind of this parameter?

   private void insertWord(String word, boolean override)

Also if you could provide more information about insert and non-insert mode from refill method.

It does not compile with Java 8.

[ant:javac] /mnt/sdb1/p2j/10266a/src/com/goldencode/p2j/ui/client/FillIn.java:2219: error: cannot find symbol
[ant:javac]                   ptr.setCursorOffset(ptr.getText().stripTrailing().length() - 1);
[ant:javac]                                                    ^
[ant:javac]   symbol:   method stripTrailing()
[ant:javac]   location: class String
[ant:javac] /mnt/sdb1/p2j/10266a/src/com/goldencode/p2j/ui/client/FillIn.java:3988: error: cannot find symbol
[ant:javac]          String newTextAfterShifting = (newTextAfterDeletion.stripTrailing().length() == 0) ?
[ant:javac]                                                             ^
[ant:javac]   symbol:   method stripTrailing()
[ant:javac]   location: variable newTextAfterDeletion of type String
[ant:javac] /mnt/sdb1/p2j/10266a/src/com/goldencode/p2j/ui/client/FillIn.java:3989: error: cannot find symbol
[ant:javac]                newTextAfterDeletion + getNextInGroup().getText().stripTrailing() :
[ant:javac]                                                                 ^
[ant:javac]   symbol:   method stripTrailing()
[ant:javac]   location: class String

I changed the stripTrailing() method to the StringHelper.safeTrimTrailing() method.

Committed on 10266a at revision 16053.

Vladimir Tsichevski wrote:

It does not compile with Java 8.
[...]

Now it compiles with Java 8.

Testing results:

The original two issues have been resolved.

New Issue Discovered

1. Enter 3 characters a b into the first txt1.
2. Move the caret to position 0.
3. Type two spaces before the a b.

In OE, upon entering the second space, the b shifts to txt2, the focus remains in txt1, the text in txt1 becomes a (two spaces followed by a), and the caret moves to position 2 before a.
In FWD, upon entering the second space, the text in txt1 becomes empty, while the text in txt2 becomes a b (noting one trailing space).

Ionut-Mihai Simioniuc wrote:

I've found 4 more testcases, which I added to the tests file.
I fixed all issues, now all the test cases pass.

Committed on 10266a at revision 16054.

Please review, Vladimir !

New issues discovered (tested with the 10266a revision 16054):

Spaces in CHARACTER Mode¶

Run this program in CHARACTER mode.

Issue 1¶

1. In txt1, press SPACE four or more times.
2. Upon entering the fourth space, the caret moves to txt2.

Note: This behavior applies consistently in both INSERT mode on and off, with no noticeable difference.

In FWD, pressing SPACE for the fourth time resets the caret to position 0 in txt1 instead.

Issue 2¶

1. Shift focus to txt2 and press SPACE four or more times.
2. Starting with the fourth space and for all subsequent spaces, no action occurs; the caret remains at the rightmost position in txt2.

Note: This behavior applies consistently in both INSERT mode on and off, with no noticeable difference.

In FWD, pressing SPACE for the fourth time incorrectly resets the caret to position 0 in txt2 instead.

Caret Position and Selection Issue in GUI Mode¶

Run this program in GUI mode.

Steps to Reproduce¶

1. Enter some text into txt1.
2. Move the caret to any position or select any portion of the text.
3. Use the mouse to shift focus to txt2.
4. Use the TAB key to return focus to txt1.

In OE, the caret position and/or selection in txt1 are restored when focus is regained in this manner.
In FWD, the entire text is selected, and the caret is positioned at the end of the selection instead.

Note: This caret position and selection restoration behavior is specific to grouped FILL-IN widgets.

So I’m not sure if I fully understand, are these two issues related to grouped FILL-IN behavior?
In 4GL, using the following test case:

DEFINE VARIABLE txt1 AS CHARACTER NO-UNDO FORMAT "X(4)".
DEFINE VARIABLE txt2 AS CHARACTER NO-UNDO FORMAT "X(4)".
SET TEXT(txt1 txt2).
DEFINE FRAME f txt1 txt2.
ENABLE ALL WITH FRAME f.

WAIT-FOR CLOSE OF FRAME f.

Ionut-Mihai Simioniuc wrote:

So I’m not sure if I fully understand, are these two issues related to grouped FILL-IN behavior?

All issues I reported here are for grouped FILL-IN widgets,

In 4GL, using the following test case:
[...]
the behavior seems the same as the one I’ve implemented. Perhaps I don’t quite understand what you mean by 'CHARACTER MODE'? Is there maybe a specific property that changes the behavior of fill-ins when used in grouped mode?

In OE, CHARACTER mode is designed for clients operating within a character-based terminal environment (e.g., physical character terminals, Windows CMD, or Unix terminal windows), in contrast to GUI mode, which is used when the client runs in a graphical environment (e.g., Windows).

I have fixed the tab cursor offset issue.
Committed on 10266a at revision 16055.

    Enter some text into txt1.
    Move the caret to any position or select any portion of the text.
    Use the mouse to shift focus to txt2.
    Use the TAB key to return focus to txt1.

In OE, the caret position and/or selection in txt1 are restored when focus is regained in this manner.
In FWD, the entire text is selected, and the caret is positioned at the end of the selection instead.

However, there's still an issue. If I reproduce it a second time, the cursor offset gets reset, while in 4GL, the caret remains in its original position.

Here is why it gets reset the second time :
In FillIn.activate()

// reset the cursor position
            if (!skipCursorActivation)
            {
               config.appDataPres.activate();
            }
            else
            {
               skipCursorActivation = false;
            }

Ionut-Mihai Simioniuc wrote:

Vladimir, I tested in CHUI mode, and the behavior is completely different in many scenarios.
So far, my implementation has only addressed GUI mode. CHUI will need to be handled separately, and I’ll have to make several changes to support it properly.
Would it be okay to open a separate task for CHUI and keep this one focused solely on GUI mode?

I’d prefer to keep this task focused exclusively on the CHARACTER (ChUI) mode issue, as it explicitly stated in the task title: "Incorrect Input Handling in Grouped CHARACTER FILL-INs."
Instead of opening a separate task, I suggest we review the changes made so far and consider committing revision 10266a. Any remaining unaddressed issues can be summarized in this task for future resolution by your or another assignee.

Hynek, Constantin, what do you think?

OKay, then I'm now trying to fix the CHUI's behavior.

Ionut-Mihai Simioniuc wrote:

However, there's still an issue. If I reproduce it a second time, the cursor offset gets reset, while in 4GL, the caret remains in its original position.

Confirmed. Also the selection issue is not resolved still.

Confirmed. Also the selection issue is not resolved still.

Hmm, what do you mean it's not resolved? For me, when I press Tab, the focus moves back to the previous fill-in at its initial position, without any selection. If you're still experiencing the issue, could you share the scenario?

Vladimir Tsichevski wrote:

I’d prefer to keep this task focused exclusively on the CHARACTER (ChUI) mode issue, as it explicitly stated in the task title: "Incorrect Input Handling in Grouped CHARACTER FILL-INs."
Instead of opening a separate task, I suggest we review the changes made so far and consider committing revision 10266a. Any remaining unaddressed issues can be summarized in this task for future resolution by your or another assignee.

Hynek, Constantin, what do you think?

Yes, let's not extend the scope of the issue, unless we have a customer reported case or a regression.

Ionut-Mihai Simioniuc wrote:

Confirmed. Also the selection issue is not resolved still.

Hmm, what do you mean it's not resolved? For me, when I press Tab, the focus moves back to the previous fill-in at its initial position, without any selection.

And this is not the correct behavior. The selection is expected to be restored.

Text Field Overflow Handling Discrepancy¶

Run the program in either GUI or CHARACTER mode.

1. Enter a 4-character text into txt1, e.g., asdf.
2. Enter one additional printable character. This character is not inserted, as the resulting text is intended to shift to txt2 but exceeds its capacity.

In OE, the error message Text field `asdf` doesn't fit in next text field (4136) is displayed.
In FWD, no error is reported.

Vladimir Tsichevski wrote:

Text Field Overflow Handling Discrepancy¶

Run the program in either GUI or CHARACTER mode.

1. Enter a 4-character text into txt1, e.g., asdf.
2. Enter one additional printable character. This character is not inserted, as the resulting text is intended to shift to txt2 but exceeds its capacity.

In OE, the error message Text field `asdf` doesn't fit in next text field (4136) is displayed.
In FWD, no error is reported.

Yes, I handled this case, but I didn’t throw an explicit error, I simply left it without any action.
So, do you want an exception to be thrown in this case?

Ionut-Mihai Simioniuc wrote:

Vladimir Tsichevski wrote:

Text Field Overflow Handling Discrepancy¶

Run the program in either GUI or CHARACTER mode.

1. Enter a 4-character text into txt1, e.g., asdf.
2. Enter one additional printable character. This character is not inserted, as the resulting text is intended to shift to txt2 but exceeds its capacity.

In OE, the error message Text field `asdf` doesn't fit in next text field (4136) is displayed.
In FWD, no error is reported.

Yes, I handled this case, but I didn’t throw an explicit error, I simply left it without any action.
So, do you want an exception to be thrown in this case?

The action taken must match that in OE.

The action taken must match that in OE.

But I don't know yet how to open an new frame that showed the error message, like in OE.
If you have any tips in this regard.

Ionut-Mihai Simioniuc wrote:

The action taken must match that in OE.

But I don't know yet how to open an new frame that showed the error message, like in OE.
If you have any tips in this regard.

I am not sure whether we should raise an error or just pop up an error message box in the client here.

Hynek, Constantin, can you help us with this?

Vladimir Tsichevski wrote:

Ionut-Mihai Simioniuc wrote:

The action taken must match that in OE.

But I don't know yet how to open an new frame that showed the error message, like in OE.
If you have any tips in this regard.

I am not sure whether we should raise an error or just pop up an error message box in the client here.

Hynek, Constantin, can you help us with this?

The behavior should match OE.

I've fixed the CHUI issue.

Committed on 10266a at revision 16056.

The cursor now moves to the next fill in when the spacebar is pressed. Also I fixed an insertion issue.

And this is not the correct behavior. The selection is expected to be restored.

I fixed this.

Committed on 10266a at revision 16057.

Please review, Vladimir!

Hynek Cihlar wrote:

I am not sure whether we should raise an error or just pop up an error message box in the client here.

Hynek, Constantin, can you help us with this?

The behavior should match OE.

I’ve already mentioned this in the two messages above :-(. The key question is how to experimentally determine which of the two approaches OE employs.

Done!

Committed on 10266a at revision 16058.

Ionut-Mihai Simioniuc wrote:

Done!

Committed on 10266a at revision 16058.

Could you rebase 10266a to the latest trunk, please.

Could you rebase 10266a to the latest trunk, please.

Sure. Done!

Testing 10266a rev. 16134.

I've entered "a b" into the first FILL-IN (format "X(8)"). The last character "b" was not entered due to ArrayIndexOutOfBoundsException here:

java.lang.ArrayIndexOutOfBoundsException
    at java.lang.System.arraycopy(Native Method)
    at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1215)
    at java.lang.StringBuilder.insert(StringBuilder.java:343)
    at com.goldencode.p2j.ui.client.FillIn.insertCharAtIndex(FillIn.java:4308)
    at com.goldencode.p2j.ui.client.FillIn.handleSimpleInsert(FillIn.java:4129)
    at com.goldencode.p2j.ui.client.FillIn.handleGUIInsertMode(FillIn.java:4067)
    at com.goldencode.p2j.ui.client.FillIn.refill(FillIn.java:3937)
    at com.goldencode.p2j.ui.client.FillIn.processKeyEvent(FillIn.java:1559)
    at com.goldencode.p2j.ui.client.gui.FillInGuiImpl.processKeyEvent(FillInGuiImpl.java:1385)
    ...

The exception was ignored in ThinClient here:

         catch (Exception e)
         {
            LOG.severe("", e);
            continue;
            // throw new RuntimeException("")
         }

Similar situation when I am entering two spaces into an empty txt1 FILL-IN, the character is not added due to:

Thread [main] (Suspended (exception ArrayIndexOutOfBoundsException))    
    StringBuilder(AbstractStringBuilder).insert(int, char) line: 1215    
    StringBuilder.insert(int, char) line: 343    
    FillInGuiImpl(FillIn<O,C>).insertCharAtIndex(String, int, char) line: 4308    
    FillInGuiImpl(FillIn<O,C>).handleSimpleInsert(String, int, int, int) line: 4129    
    FillInGuiImpl(FillIn<O,C>).handleGUIInsertMode(int) line: 4067    
    FillInGuiImpl(FillIn<O,C>).refill(boolean, int, boolean) line: 3937    
    FillInGuiImpl(FillIn<O,C>).processKeyEvent(KeyInput) line: 1559    
    FillInGuiImpl.processKeyEvent(KeyInput) line: 1385    

Issue

1. Run the program in GUI mode.
2. Enter text into all FILL-IN widgets within the group.
3. In any grouped FILL-IN widget, select all text using Ctrl-A and delete it with the Delete key.

In OE, only the text within the selected FILL-IN widget is deleted.
In FWD, the text in the selected FILL-IN widget and all subsequent grouped FILL-IN widgets is deleted.

Is this task active still?