FWD » Core Development » User Interface

Like Vladimir wrote in #10736-11, the issues are these:

• When the user types a value and then switches to the list by pressing DOWN:
  In OE: The matching item is selected (or the first item if no match).
  In FWD: The previously selected item is re-selected.
• When the user switches to the list with DOWN, then presses Left or Right, then Down or Up:
  In OE: The next (for Down) item or previous (for Up) item is selected, and the VALUE-CHANGED event is triggered with the newly selected value.
  In FWD: The selected item remains the same, the VALUE-CHANGED event is triggered for this currently selected item.

This can be reproduced by any testcase which implies a simple COMBO-BOX (with an entry field), but here is a testcase:

DEF VAR cb1 AS CHARACTER
     VIEW-AS COMBO-BOX INNER-LINES 10
     LIST-ITEMS 
     "a", "b", "c" 
     SIMPLE
     SIZE 40 BY 5
     NO-UNDO.

DEFINE FRAME f
    cb1
    WITH 1 DOWN SIDE-LABELS.
ENABLE ALL WITH FRAME f. 

DEFINE VAR i AS INTEGER NO-UNDO INITIAL 0.

ON VALUE-CHANGED OF cb1 DO:
    i = i + 1.
    MESSAGE cb1:SCREEN-VALUE i.
END.

WAIT-FOR CLOSE OF CURRENT-WINDOW.

I've noticed that in FWD, if we write something (different from the first list item) in the entry field and press DOWN, the selection is made correctly. If we delete the text from entry field while the item is selected in the list and introduce a value that match with the first item and press DOWN then, the previous item remains selected. If we write something else in the entry field and press DOWN, the selection in the list is made correctly.

Delia Mitric wrote:

I've noticed that in FWD, if we write something (different from the first list item) in the entry field and press DOWN, the selection is made correctly. If we delete the text from entry field while the item is selected in the list and introduce a value that match with the first item and press DOWN then, the previous item remains selected. If we write something else in the entry field and press DOWN, the selection in the list is made correctly.

More than that, I've found now that in FWD this happens just for a combo-box which have a list for which all the items fits in the space of the combo-box (no scrollbar).

I think I found another difference between FWD and Progress when an item from the list is selected based on the entry field text:
Scenario: introduce a text which has the same prefix like an item from the list (but the list don't contain an item with exactly the same full text) and press DOWN:

• In Progress: because the text from the entry field is not entirely found in the list, the first list item will be selected
• In FWD: the element with the same prefix is selected

If we fix this can help for solving the second problem described in #10791-1

Delia Mitric wrote:

I think I found another difference between FWD and Progress when an item from the list is selected based on the entry field text:
Scenario: introduce a text which has the same prefix like an item from the list (but the list don't contain an item with exactly the same full text) and press DOWN:

• In Progress: because the text from the entry field is not entirely found in the list, the first list item will be selected
• In FWD: the element with the same prefix is selected

If we fix this can help for solving the second problem described in #10791-1

Several team members are currently working on COMBO-BOX issues. To improve coordination, I suggest creating a central hub task, such as "COMBO-BOX Issues," and linking all related issues to it.

Vladimir Tsichevski wrote:

Several team members are currently working on COMBO-BOX issues. To improve coordination, I suggest creating a central hub task, such as "COMBO-BOX Issues," and linking all related issues to it.

Done :). The task is #10801

I think we need to modify when the selection is cleared for a ScrollableSelectionListGuiImpl list in EntryFieldGuiImpl.processKeyEvent to solve the second issue from the first note.

When CURSOR_LEFT or CURSOR_RIGHT events are processed for an entry field, the selection from entry field and list is cleared. The selection from the list shouldn't be cleared if the entry field text wasn't changed (the cursor just moved LEFT/RIGHT in the entry field).

Code Review 10791a, Revision 16253

EntryFieldGuiImpl

Update the copyright message years to 2015–2025.

The change is otherwise good.

Vladimir Tsichevski wrote:

Code Review 10791a, Revision 16253

EntryFieldGuiImpl

Update the copyright message years to 2015–2025.

The change is otherwise good.

Done (rev. 16254).
So, can we proceed with the testing?

Delia Mitric wrote:

Vladimir Tsichevski wrote:

Code Review 10791a, Revision 16253

EntryFieldGuiImpl

Update the copyright message years to 2015–2025.

The change is otherwise good.

Done (rev. 16254).
So, can we proceed with the testing?

Please, rebase 10791a to the recent trunk.

Vladimir Tsichevski wrote:

Delia Mitric wrote:

Vladimir Tsichevski wrote:

Code Review 10791a, Revision 16253

EntryFieldGuiImpl

Update the copyright message years to 2015–2025.

The change is otherwise good.

Done (rev. 16254).
So, can we proceed with the testing?

Please, rebase 10791a to the recent trunk.

10791a rebased to the recent trunk

Delia Mitric wrote:

Vladimir Tsichevski wrote:

Delia Mitric wrote:

Vladimir Tsichevski wrote:

Code Review 10791a, Revision 16253

EntryFieldGuiImpl

Update the copyright message years to 2015–2025.

The change is otherwise good.

Done (rev. 16254).
So, can we proceed with the testing?

Please, rebase 10791a to the recent trunk.

10791a rebased to the recent trunk

I still see 16254. Probably, you did not push the branch after rebase?

Vladimir Tsichevski wrote:

I still see 16254. Probably, you did not push the branch after rebase?

Yes, that's it. Now it should be rebased.

Delia Mitric wrote:

Vladimir Tsichevski wrote:

I still see 16254. Probably, you did not push the branch after rebase?

Yes, that's it. Now it should be rebased.

Core review and testing: 10791a rev. 16280.

The change looks good and fixes the original issue.

Should we proceed by setting the status to Internal Test?

Delia Mitric wrote:

Should we proceed by setting the status to Internal Test?

Yes

What I'll do:

• run the xfer tests for a COMBO-BOX widget
• smoke testing on a GUI Customer App

I'll talk with Razvan for ChUI tests and with Serban for smoke testing on another GUI Customer app.

Delia Mitric wrote:

What I'll do:

• smoke testing on a GUI Customer App

This is done. No regression found.

Customer smoke tests passed.

Besides the mentions in #10736-45, I have nothing to add.

ChUI regression tests passed for 10791a.

Delia Mitric wrote:

What I'll do:

• run the xfer tests for a COMBO-BOX widget

Related xfer tests passed.

No more testing needed.
I think this is ready for merge.