Project

General

Profile

Bug #8809

Incorrect next enabled widget calculation

Added by Vladimir Tsichevski about 2 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

8809.p Magnifier (2 KB) Vladimir Tsichevski, 05/23/2024 04:45 PM

functions.i (1.71 KB) Vladimir Tsichevski, 05/23/2024 04:46 PM

printEntryLeave.i (134 Bytes) Vladimir Tsichevski, 05/23/2024 04:46 PM

Related issues

Related to User Interface - Bug #8673: Deduce the logic behind OE focus management and implement in FWD WIP

History

#1 Updated by Vladimir Tsichevski about 2 years ago

Run the 8809.p example.

In OE, the focusable7 button receives focus.
In FWD no focus is set.

The issue origin is in the FWD Frame.getNextEnabledWidget(Widget<O> widget, boolean wrap) method, which is supposed to find a TAB-STOP field, which follow the given TAB-STOP field in the window tab ring.

This method first searches the frame own widgets, then if no matching widget found, continues with the next frame sibling and so on.

But this search in the next frame sibling does not happen in these cases:

  1. the frame has no widgets:
          if (widgets == null)
      {
         return null;
      }
  2. the method argument widget is the last frame widget:
          if (nref == size)
      {
         return null;
      }

which is incorrect for both cases.

#2 Updated by Vladimir Tsichevski about 2 years ago

  • Related to Bug #8673: Deduce the logic behind OE focus management and implement in FWD added

#3 Updated by Vladimir Tsichevski about 2 years ago

  • Status changed from New to WIP
  • % Done changed from 0 to 100

Fixed in 8809a rev. 15240. Please, review.

#4 Updated by Vladimir Tsichevski about 2 years ago

  • Status changed from WIP to Review

#5 Updated by Vladimir Tsichevski about 2 years ago

The (incomplete) fix for #8770 reverted in 8809a in rev. 15241.

#6 Updated by Greg Shah about 2 years ago

Hynek: Please review.

#7 Updated by Hynek Cihlar about 2 years ago

  • Status changed from Review to Internal Test

Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.

#8 Updated by Vladimir Tsichevski about 2 years ago

Hynek Cihlar wrote:

Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.

I have trouble deciding which FWD branch to use for ChUI testing, since the 6667i is currently far behind trunk.

#9 Updated by Greg Shah about 2 years ago

6667g is based on a recent trunk. It can't be migrated back to 6667i because GSO 440 fails (some regression caused by trunk). Other than that, ChUI regression testing passes.

You can use 6667g.

#10 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

6667g is based on a recent trunk.

6667g is based on trunk rev. 15270 of 2024-06-05, while the current trunk is 15310.

#11 Updated by Vladimir Tsichevski about 2 years ago

Hynek Cihlar wrote:

Code review 8809a. The changes look good, but it will require good amount of regression testing, including ChUI regression tests.

Testing with ChUI suite succeeded (the 6667g was used as the base).

#12 Updated by Greg Shah about 2 years ago

Have you tested this with a customer's large GUI application?

#13 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

Have you tested this with a customer's large GUI application?

I will do smoke test only. I do not know about any issues in a customer's large GUI application related to this issue problem.

#14 Updated by Greg Shah about 2 years ago

I'm more concerned with trying various scenarios to see if there is any breakage.

#15 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

I'm more concerned with trying various scenarios to see if there is any breakage.

I spend a few minutes opening various screens in the big application, and I saw no problems.

#16 Updated by Hynek Cihlar about 2 years ago

  • Status changed from Internal Test to Merge Pending

Vladimir Tsichevski wrote:

Greg Shah wrote:

I'm more concerned with trying various scenarios to see if there is any breakage.

I spend a few minutes opening various screens in the big application, and I saw no problems.

Since the ChUI tests also passed (they contain a lot of tabbing sensitive code) I would consider the regression testing passed.

#17 Updated by Greg Shah about 2 years ago

You can merge to trunk now.

#18 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

You can merge to trunk now.

Done. Trunk rev. 15314.

#19 Updated by Greg Shah about 2 years ago

  • Status changed from Merge Pending to Test

#20 Updated by Vladimir Tsichevski 10 months ago

Can this be closed?

#21 Updated by Hynek Cihlar 5 months ago

  • Status changed from Test to Closed

Also available in: Atom PDF