FWD » Core Development » User Interface

Menu item action are not triggered, if menu items were added after the frame becomes visible.

In the following example new menu items are created dynamically by selecting the first menu item. These dynamic items are visible and responsible, but they trigger no actions.

DEFINE FRAME theFrame WITH SIZE 60 BY 10.
ENABLE ALL WITH FRAME theFrame.

DEFINE VARIABLE ghMenu AS HANDLE.
DEFINE VARIABLE hItem AS HANDLE.

CREATE MENU ghMenu
   ASSIGN popup-only = TRUE.

CREATE MENU-ITEM hItem
   ASSIGN PARENT = ghMenu
      LABEL  = 'Add more items'
      SENSITIVE = TRUE
      TRIGGERS:
         ON CHOOSE
            CREATE MENU-ITEM hItem
               ASSIGN PARENT = ghMenu
               LABEL  = 'Say hello'
               SENSITIVE = TRUE
               TRIGGERS:
                  ON CHOOSE
                    MESSAGE "Hello, world!" VIEW-AS ALERT-BOX.
               END TRIGGERS.
      END TRIGGERS.

ASSIGN
   FRAME theFrame:POPUP-MENU = ghMenu.

WAIT-FOR CLOSE OF THIS-PROCEDURE.

Greg Shah wrote:

Is the solution as simple as putting TriggerManager.mergeTriggerRegistry() in a finally block for the LogicalTerminal.trigger(int, int, int, int, long, int, ScreenBuffer[])?

Greg, which argument should be passed to mergeTriggerRegistry() here?

We have nothing to pass other than lt.scope. I suspect that dynamically created widgets with TRIGGERS clauses are probably not associated with a particular scope in the 4GL. I think that we don't handle that properly. The code will generate as a call to LT.registerTrigger(EventList, Object, Trigger) which will register in the current scope. The current scope will be popped at the end of the trigger so the registration will go away.

Constantin: If we emit a boolean 4th parameter for triggers that are part of a CREATE WIDGET, this will force persistent registration. Will we cleanup properly when the widget is destroyed?

Assuming any scoping registration issue is fixed, instead of just a call to mergeTriggerRegistry(), I think we need to have something more like the processing in LT.invokeOnServer() which calculates the differences in the triggers and stores those diffs in the ServerReturnValue for return to the client.

Greg, the TRIGGERS phrase is the same as explicitly registering a trigger with a handle:

on choose of h do:
   message "h".
end.

Vladimir, I can't run your testacase using OE116.3 - it abends from the procedure editor. Also, a testcase like:

def var h as handle.

form with frame f1 size 10 by 10.

on "1" anywhere do:
   create button h
   assign frame = frame f1:handle
          sensitive = true
          label = "bar" 
          row = 1
          column = 1
          visible = true
   triggers:
       on choose message "chosen".
   end.
end.
enable all with frame f1.
wait-for go of frame f1.

doesn't allow the button's trigger to fire in OE, as the registration is 'popped' when the trigger's scope is finished.

Please describe better what the issue is. Are you sure the issue is with FWD not registering or popping the trigger definition too early?