Project

General

Profile

Bug #10857

Logical FILL-IN initial state: Incorrect handling of unmatched keys

Added by Vladimir Tsichevski 8 months ago. Updated 6 months ago.

Status:
Test
Priority:
Normal
Assignee:
Delia Mitric
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
16264
version_resolved:
reviewer:
Hynek Cihlar, Vladimir Tsichevski
production:
No
env_name:
topics:

Related issues

Related to User Interface - Bug #10856: Logical FILL-IN: Caret position issues Test
Related to User Interface - Bug #11078: Unintended VALUE-CHANGED Event Triggering in DECIMAL, INTEGER, and LOGICAL FILL-IN Widgets New

History

#1 Updated by Vladimir Tsichevski 8 months ago

Run this simplest possible example in GUI mode:

DEFINE VARIABLE l AS LOGICAL NO-UNDO.
DEFINE FRAME f l NO-LABEL.
ENABLE ALL WITH FRAME f.
WAIT-FOR WINDOW-CLOSE OF FRAME f.

In this example, a frame with a single FILL-IN of LOGICAL type with the default (yes/no) format is displayed and enabled.

As already mentioned in #10856, Issue 1: the initial caret position in FWD is 1 instead of 0.

In this initial state, if the user enters any printable key other than the initial matches (y or n):

In OE: Nothing happens.

In FWD: The FILL-IN displayed value is reset to unknown (?).

#2 Updated by Vladimir Tsichevski 8 months ago

  • Related to Bug #10856: Logical FILL-IN: Caret position issues added

#3 Updated by Delia Mitric 7 months ago

I'll take a look into this.

#4 Updated by Delia Mitric 7 months ago

  • Assignee set to Delia Mitric

#5 Updated by Delia Mitric 7 months ago

If we click on the FILL-IN or use LEFT, RIGHT in the FILL-IN to move the cursor and after that we introduce any printable key different from "y" and "n", the displayed value in FWD is the same like in OE (no value displayed).
? is displayed in FWD just if we introduce directly a printable key without changing the cursor position.

#6 Updated by Vladimir Tsichevski 7 months ago

Delia Mitric wrote:

If we click on the FILL-IN or use LEFT, RIGHT in the FILL-IN to move the cursor and after that we introduce any printable key different from "y" and "n", the displayed value in FWD is the same like in OE (no value displayed).
? is displayed in FWD just if we introduce directly a printable key without changing the cursor position.

Yes. I think, the non-zero initial caret position is the key and should be fixed first.

#7 Updated by Delia Mitric 7 months ago

  • Status changed from New to WIP

#8 Updated by Delia Mitric 7 months ago

Found why the caret is initially set to 1:
FillInGuiImpl.getInitialCursorPos() returns the position of the cursor (which is to the right of the text). We expect FILL-IN SCREEN-VALUE to be "", but in FWD it is "?". The length of this text affects the cursor position.

#9 Updated by Delia Mitric 7 months ago

  • % Done changed from 0 to 10

#10 Updated by Delia Mitric 7 months ago

  • % Done changed from 10 to 100
  • Status changed from WIP to Review

I've committed a solution to 10857a, rev. 16321.
The caret position is fixed (initially is 0) and if we introduce a printable key different from "y" or "n", nothing happens which is correct.

Vladimir/Hynek, can you review, please?
Thank you!

#11 Updated by Vladimir Tsichevski 7 months ago

Delia Mitric wrote:

I've committed a solution to 10857a, rev. 16321.

Code review and testing: the change is good, the issue is fixed.

#12 Updated by Greg Shah 7 months ago

  • Status changed from Review to Internal Test
  • reviewer Vladimir Tsichevski added

What testing do you suggest?

#13 Updated by Razvan-Nicolae Chichirau 7 months ago

ChUI regression tests passed with 10857a.

#14 Updated by Delia Mitric 6 months ago

Smoke testing for another GUI Customer app is done. No regressions found.

#15 Updated by Vladimir Tsichevski 6 months ago

Vladimir Tsichevski wrote:

Delia Mitric wrote:

I've committed a solution to 10857a, rev. 16321.

Code review and testing: the change is good, the issue is fixed.

It also fixes the #10856, issue 1.

#16 Updated by Delia Mitric 6 months ago

Serban tested another Customer GUI application. No regression found.

#17 Updated by Delia Mitric 6 months ago

The testing phase is done.
I think this is ready to be merged

#18 Updated by Radu Apetrii 6 months ago

  • Status changed from Internal Test to Merge Pending

Seems fair. 10857a can be merged right now.

#19 Updated by Delia Mitric 6 months ago

  • Status changed from Merge Pending to Test

Branch 10857a was merged into trunk as rev. 16364 and archived.

#20 Updated by Vladimir Tsichevski 6 months ago

  • Related to Bug #11078: Unintended VALUE-CHANGED Event Triggering in DECIMAL, INTEGER, and LOGICAL FILL-IN Widgets added

Also available in: Atom PDF