Bug #8872: WAIT-FOR with FOCUS explicitly specified: NO-APPLY return from ENTRY trigger must be ignored - User Interface - Golden Code Redmine

Bug #8872

WAIT-FOR with FOCUS explicitly specified: NO-APPLY return from ENTRY trigger must be ignored

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

Status:

WIP

Priority:

Normal

Assignee:

Target version:

Start date:

Due date:

% Done:

50%

billable:

vendor_id:

GCD

case_num:

version_reported:

version_resolved:

reviewer:

production:

env_name:

topics:

8770-explicit-focus.p (1.45 KB) Vladimir Tsichevski, 06/12/2024 04:25 PM

functions.i (1.95 KB) Vladimir Tsichevski, 06/12/2024 04:25 PM

printEntryLeave.i (134 Bytes) Vladimir Tsichevski, 06/12/2024 04:26 PM

Related issues

History

#1 Updated by Vladimir Tsichevski about 2 years ago

File printEntryLeave.i added
File 8770-explicit-focus.p added
File functions.i added
Subject changed from WAIT-FOR with FOCUS explicitly specified: the NO-APPLY return from ENTRY trigger must be ignored to WAIT-FOR with FOCUS explicitly specified: NO-APPLY return from ENTRY trigger must be ignored

The WAIT-FOR statement can include the FOCUS option. The initial focus must be set to the widget, specified as this option argument.
An ENTRY event is sent to this widget.

OE: the ENTRY event return value is ignored, and the focus is always set to the widget.
FWD: the ENTRY event return value is honored, and the focus is not set to the widget, if the trigger returns NO-APPLY.

The attached 8770-explicit-focus.p illustrated this:

In OE the focus is set to focusable2
In FWD the focus is set to focusable3

#2 Updated by Vladimir Tsichevski about 2 years ago

Related to Bug #8770: ENTRY event is not sent for a frame when window receives focus added

#3 Updated by Vladimir Tsichevski about 2 years ago

Related to deleted (Bug #8770: ENTRY event is not sent for a frame when window receives focus)

#4 Updated by Vladimir Tsichevski about 2 years ago

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

#5 Updated by Vladimir Tsichevski about 2 years ago

% Done changed from 0 to 50
Status changed from New to WIP

The following change fixes this very issue:

=== modified file 'src/com/goldencode/p2j/ui/client/FocusManager.java'
--- old/src/com/goldencode/p2j/ui/client/FocusManager.java    2024-02-05 14:53:56 +0000
+++ new/src/com/goldencode/p2j/ui/client/FocusManager.java    2024-06-13 12:57:10 +0000
@@ -794,7 +794,7 @@
          // send ENTRY event and see the response
          boolean check = tc.sendEntry(next);

-         if (check || fastExit)
+         if (next == toFocus || check || fastExit)
          {
             // ignore NO-APPLY if there is a fast exit

The fix is also in 8872a, rev. 15283.

#6 Updated by Vladimir Tsichevski about 2 years ago

Other difference, which can be seen after the main issue fixed:

OE: before the ENTRY is sent to the focusable2 in 8770-explicit-focus.p, the focus is set to focusable2.
FWD: focus is undefined in the focusable2 ENTRY trigger code.

Shall I fix this here or open another issue for this?

#7 Updated by Greg Shah about 2 years ago

Is this seen in customer code?

the focus is set to focusable2

Are you referring to the FOCUS system handle?

#8 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

Is this seen in customer code?

the focus is set to focusable2

I do not know.

Are you referring to the FOCUS system handle?

Yes, exactly. The FOCUS handle is printed in the example on every ENTRY.

#9 Updated by Greg Shah about 2 years ago

You might as well resolve it here.

#10 Updated by Vladimir Tsichevski about 2 years ago

Greg Shah wrote:

You might as well resolve it here.

I did. Now the change causes addition failed tests in the ChUI test suite.

Investigating...

#11 Updated by Vladimir Tsichevski about 2 years ago

An additional issue related to WAIT-FOR with explicit focus discovered:
In the following modified version of 8770-explicit-focus.p:

DEFINE FRAME outerFrame
WITH SIZE 80 BY 15
AT COL 1 ROW 1.

DEFINE BUTTON focusable2.
DEFINE BUTTON focusable4.
DEFINE FRAME innerFrame
  focusable2
  focusable4
  WITH SIZE 60 BY 2
  AT COLUMN 1 ROW 1.
FRAME innerFrame:FRAME = FRAME outerFrame:HANDLE.

DEFINE BUTTON focusable3.
DEFINE FRAME innerFrame2
  focusable3
  WITH SIZE 60 BY 2
  AT COLUMN 1 ROW 5.
FRAME innerFrame2:FRAME = FRAME outerFrame:HANDLE.

{functions.i}

{printEntryLeave.i &widget="DEFAULT-WINDOW"}
{printEntryLeave.i &widget="FRAME outerFrame"}
{printEntryLeave.i &widget="FRAME innerFrame"}
{printEntryLeave.i &widget="FRAME innerFrame2"}

{printEntryLeave.i &widget="focusable2"}
{printEntryLeave.i &widget="focusable3"}
{printEntryLeave.i &widget="focusable4"}

ON ENTRY OF focusable4 DO:
   RUN PrintEntry(SELF:HANDLE).
   RETURN NO-APPLY.
END.

ENABLE focusable2 focusable4 WITH FRAME innerFrame.
ENABLE focusable3 WITH FRAME innerFrame2.

focusable2:TAB-STOP = FALSE.
focusable4:TAB-STOP = FALSE.
focusable3:TAB-STOP = FALSE.

VIEW FRAME outerFrame.
WAIT-FOR GO OF FRAME outerFrame
  FOCUS focusable4
  .

Comparing with the original example code, TAB-STOP is reset for all fields, and the explicitly focused widget ENTRY trigger returns NO-APPLY.

In this case in OE the ENTRY event is sent to focusable4, innerFrame and the DEFAILT-WINDOW.

In FWD, the only ENTRY event is sent to focusable4.

#12 Updated by Vladimir Tsichevski about 2 years ago

One mode difference for the following modification of the original example:

DEFAULT-WINDOW:TITLE = '8770-explicit-focus'.

DEFINE FRAME outerFrame
WITH SIZE 80 BY 15
AT COL 1 ROW 1.

DEFINE BUTTON focusable2.
DEFINE BUTTON focusable4.
DEFINE FRAME innerFrame
  focusable2
  focusable4
  WITH SIZE 60 BY 2
  AT COLUMN 1 ROW 1.
FRAME innerFrame:FRAME = FRAME outerFrame:HANDLE.

DEFINE BUTTON focusable3.
DEFINE FRAME innerFrame2
  focusable3
  WITH SIZE 60 BY 2
  AT COLUMN 1 ROW 5.
FRAME innerFrame2:FRAME = FRAME outerFrame:HANDLE.

{functions.i}

{printEntryLeave.i &widget="DEFAULT-WINDOW"}
{printEntryLeave.i &widget="FRAME outerFrame"}
{printEntryLeave.i &widget="FRAME innerFrame"}
{printEntryLeave.i &widget="FRAME innerFrame2"}

{printEntryLeave.i &widget="focusable2"}
{printEntryLeave.i &widget="focusable3"}
{printEntryLeave.i &widget="focusable4"}

ON 'a' ANYWHERE DO:
  DEFINE VARIABLE hFocus AS HANDLE NO-UNDO.
  hFocus = FOCUS.
  DEFINE VARIABLE cFocusName AS CHARACTER NO-UNDO.
  IF FOCUS <> ? THEN
     cFocusName = FOCUS:NAME.
  MESSAGE "FOCUS:" cFocusName.
END.

ON ENTRY OF focusable4 DO:
   RUN PrintEntry(SELF:HANDLE).
   RETURN NO-APPLY.
END.

ENABLE focusable2 focusable4 WITH FRAME innerFrame.
ENABLE focusable3 WITH FRAME innerFrame2.

VIEW FRAME outerFrame.
WAIT-FOR GO OF FRAME outerFrame
  FOCUS focusable3
  .

Comparing with the original example code, the explicitly ENTRY trigger for focusable4 returns NO-APPLY, and focusable3 is passed as the explicit focus.

In this case in OE the ENTRY event is sent to focusable2, innerFrame, focusable3, innerFrame2 and the DEFAILT-WINDOW.

In FWD, an ENTRY event is not sent to innerFrame.

Also available in: Atom PDF

Project

General

Profile

FWD » Core Development » User Interface

Issues

Custom queries