FWD » Core Development » Runtime Infrastructure

During testing of a large customer GUI application I encountered an abend when interacting with the main (menu) window.

A synthetic test case that shows this error:

DEFAULT-WINDOW:VISIBLE = TRUE.
DEF VAR hwnd1 AS HANDLE.
CREATE WINDOW hwnd1 ASSIGN VISIBLE = TRUE.
DEFINE VAR fi1 AS INT.
DEFINE VAR fi2 AS INT.
DEFINE FRAME f1 fi1 fi2.
ENABLE ALL WITH FRAME f1 IN WINDOW hwnd1.

ON 'entry':U OF hwnd1
DO:
   def var h as handle.
   create fill-in h assign frame = frame f1:handle visible = true sensitive = true.
   apply "entry" to h.
   delete widget h.
END.

WAIT-FOR CLOSE OF THIS-PROCEDURE.

The problem is that the lookup logic for the applied entry event incorrectly chooses the window trigger.

The problematic code is in EventList.lookupWorker:

         // search the target trigger in its top level window
         if (win != null &&
             win.getId() != WidgetId.DEFAULT_WINDOW_ID &&
             win.isVisible() && !win.hidden())
         {
            // lookup event for a specific widget and honor any-printable/any-key if needed
            lookupEventHelper(rootFrame == null ? -1 : rootFrame.getId().asInt(),
                              win.getId().asInt(), ev, trig, true, false, isKey, result);
         }

First, the check for default window is very suspicious. It is unlikely the lookup logic should behave differently for default and non-default windows.
Second, the test case for choosing window trigger when applying to a specific non-window widget is unknown.

Looking at the revision history of the related code I have a suspicion that this was added to handle the case when ENTRY should be triggered for the whole widget tree when focus moved in widget from another top-level window. If this is the case, the implementation is not right, it should not be handled at this level, because there is not enough context to determine which widgets should be considered.

Fixed in 3809e revision 11356. Constantin, please review the changes.

Hynek Cihlar wrote:

Fixed in 3809e revision 11356. Constantin, please review the changes.

The changes make sense. Please run a MAJIC testing with this to see if there are any problems.

Constantin Asofiei wrote:

Hynek Cihlar wrote:

Fixed in 3809e revision 11356. Constantin, please review the changes.

The changes make sense. Please run a MAJIC testing with this to see if there are any problems.

I did run the ChUI regression tests. I found some errors, but all seem to be related to other changes in 3809e.

Branch 3809e was merged to trunk as revision 11340.

Is this task complete?