Project

General

Profile

Bug #9913

DATE FILL-IN: Unexpected normalization on Enter and Tab keys

Added by Vladimir Tsichevski over 1 year ago. Updated 7 months ago.

Status:
WIP
Priority:
Normal
Assignee:
Vladimir Tsichevski
Target version:
-
Start date:
Due date:
% Done:

50%

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

Related issues

Related to User Interface - Bug #7515: FILL-IN: editing dates issues WIP
Related to User Interface - Bug #10876: Date FILL-IN: Incorrect ENTER key handling in GUI mode Internal Test

History

#1 Updated by Vladimir Tsichevski over 1 year ago

In the OE system, a FILL-IN widget bound to a date variable normalizes its contents (aka auto-completion) only when it loses focus. This behavior is correctly replicated in FWD for focus loss. However, in FWD, normalization also occurs when the user presses the Enter key in the FILL-IN, which is not expected. In OE, pressing Enter does not alter the FILL-IN's displayed content.

A similar issue arises when the user presses the Tab key but the focus cannot shift (e.g., when no other tab stops exist in the frame). In FWD, pressing Tab triggers normalization, whereas in OE, no change occurs.

Example:

   DEFINE VARIABLE myDate AS DATE.
   DEFINE FRAME myFrame
       myDate FORMAT "99/99/9999".
   ENABLE myDate WITH FRAME myFrame.
   WAIT-FOR WINDOW-CLOSE OF CURRENT-WINDOW.

In OE, entering "1" sets the screen value to "1 / /" (with spaces per the format). Pressing Enter or Tab leaves this value unchanged. In FWD, the same input normalizes to "01/00/2025" upon pressing Enter or Tab.

#2 Updated by Vladimir Tsichevski over 1 year ago

  • Related to Bug #7515: FILL-IN: editing dates issues added

#3 Updated by Vladimir Tsichevski over 1 year ago

  • version_reported set to 15497

#4 Updated by Greg Shah over 1 year ago

In OE, pressing Enter does not alter the FILL-IN's displayed content.

Make sure you test ChUI. I think that ENTER in ChUI will shift focus to the next tab stop.

#5 Updated by Vladimir Tsichevski over 1 year ago

Greg Shah wrote:

In OE, pressing Enter does not alter the FILL-IN's displayed content.

Make sure you test ChUI. I think that ENTER in ChUI will shift focus to the next tab stop.

Yes, in the OE character mode, pressing the ENTER key shifts focus to the next widget, provided a valid target exists.

Two corrections are needed:

1. Disable the focus shift triggered by the ENTER key in FWD GUI mode.
2. Prevent actions (e.g., normalization) associated with focus shifts when the focus remains unchanged, in both FWD ChUI and GUI modes.

#6 Updated by Vladimir Tsichevski over 1 year ago

  • % Done changed from 0 to 30
  • Assignee set to Vladimir Tsichevski
  • Status changed from New to WIP

#7 Updated by Vladimir Tsichevski over 1 year ago

Vladimir Tsichevski wrote:

1. Disable the focus shift triggered by the ENTER key in FWD GUI mode.

Processing of the ENTER key moved from FillIn to FillInImpl to remove the processing in GUI mode in 9913a rev. 15867.

#8 Updated by Vladimir Tsichevski over 1 year ago

When a user presses the ENTER key in a FILL-IN widget in OE character mode, the following sequence of events is probably occurs:

  1. Check if a next tab stop exists in the tab ring. If none exists, exit.
  2. Run triggers for the ENTER event on the current widget. The RETURN value is ignored.
  3. Hide the blinking cursor from the FILL-IN, indicating focus is inactive.
  4. Run LEAVE event triggers. If a trigger returns NO-APPLY, exit.
  5. Perform auto-completion (normalization) and validate the value. If validation fails, exit.
  6. Move focus to the next tab stop in the tab ring internally, but do not show blinking cursor

Now the user presses any key, which causes:

  1. Run ENTRY event triggers for the newly focused widget. The RETURN value is ignored.
  2. Show the blinking cursor at position 0 in the new widget.
  3. The value of the FOCUS system handler changes to the newly focused widget.
  4. Discard the value of the key pressed.

The current FWD implementation differs: the auto-completion and validation is performed unconditionally before all other steps.

#9 Updated by Greg Shah over 1 year ago

Only running the ENTRY triggers after the user presses another key does not seem right.

#10 Updated by Vladimir Tsichevski over 1 year ago

Greg Shah wrote:

Only running the ENTRY triggers after the user presses another key does not seem right.

Also, the prompt "Press space bar to continue" is displayed.

#11 Updated by Vladimir Tsichevski over 1 year ago

  • % Done changed from 30 to 50

I removed the call to completeEdit() in ENTER key processing in processKeyEvents() in FillInImpl.

This was called unconditionally. Now the completeEdit() is called by the LEAVE event.
The problem is now the FILL-IN displayed value is not updated after the completeEdit() changes it.

I've done some experimenting:

  1. explicitly call completeEdit() just before the invokeTriggers call (TC. l.22153). The display is updated OK in this case. But this is incorrect, since triggers may return NO-APPLY, and this must disable the call to completeEdit().
  2. explicitly call completeEdit() just after the invokeTriggers call. This does not update the display, so this cannot help much. I've added call to repaint() but this did not help either.

The revision is now 15869.

#12 Updated by Vladimir Tsichevski 7 months ago

  • Related to Bug #10876: Date FILL-IN: Incorrect ENTER key handling in GUI mode added

#13 Updated by Vladimir Tsichevski 7 months ago

The fix in rev. 16332 of 10876a also partially resolves this issue, specifically for the Enter key.

The root cause is similar for the Tab key: the completeEdit() method is called even in cases where Tab does not trigger any other actions.
However, properly fixing this for Tab is more complex and will require additional testing.

Also available in: Atom PDF