Project

General

Profile

Bug #11631

fix issues with persistent UI triggers

Added by Constantin Asofiei 5 days ago. Updated about 6 hours ago.

Status:
WIP
Priority:
Normal
Assignee:
Razvan-Nicolae Chichirau
Target version:
-
Start date:
Due date:
% Done:

0%

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

History

#2 Updated by Constantin Asofiei 5 days ago

In #11580 there were fixed urgent problems (leaks) related to persistent UI triggers. This task is meant to fix other remaining issues:
  • an APPLY <event> TO <handle> can't find an ON ANY-KEY [ANYWHERE] trigger
  • in batch mode, ENTRY event in 4GL is not fired via APPLY; in interactive mode, the widget must be SENSITIVE (and attached to frame) for APPLY to find it
  • other issues found from testing

#3 Updated by Razvan-Nicolae Chichirau about 10 hours ago

  • Assignee set to Razvan-Nicolae Chichirau
  • Status changed from New to WIP

Constantin Asofiei wrote:

  • an APPLY <event> TO <handle> can't find an ON ANY-KEY [ANYWHERE] trigger

Testcase:

def var fi as char view-as fill-in.
def button btn.
def frame f fi skip btn.

def var hFi as handle.
hFi = fi:handle.

on ANY-KEY of hFi do:
    message "ANY-KEY".
end.

on choose of btn do:
    apply "1" to hFi.
end.

enable all with frame f.
apply "entry" to btn.
wait-for window-close of current-window.

  • in batch mode, ENTRY event in 4GL is not fired via APPLY; in interactive mode, the widget must be SENSITIVE (and attached to frame) for APPLY to find it

Please post the relevant testcases here. I wasn't able to reproduce the issue.

  • other issues found from testing

Can you describe them?

#4 Updated by Constantin Asofiei about 6 hours ago

The tests are in testcases rev 1854. They should be ran in both standalone and test-suite mode. They pass in OE, but needs to be double-checked. If ran individually, these are meant as 'batch programs'.

All checks I did until now were in batch mode (non-interactive).

About ENTRY, LEAVE, etc: the point is to have the widget not attached to a frame, not realized, etc. ENTRY from my experimenting is sent only if the widget is realized and SENSITIVE.

IMO, we will need to remove the EventList.lookup(long resourceId, boolean trigExit, TriggerMatch result) and use the main event lookup method. For this, we will need to be able to resolve easily the widget ID (if any) for a certain resource ID. I propose a maintained map in the WidgetRegistry, for (resourceID, widgetID) pairs. So that when we have a apply "x" to <resource>." we can resolve fast the widget ID and call the event lookup method. The problem: when destroying a widget, this widget needs to be removed from this map - so we need also (widgetID->resourceID) mapping.

Please thing about the above and lets find best way to do this. What I'm pretty sure we can't short-circuit the lookup when we have a resource ID as target.

Events in 4GL can be applied to any resource, but not all resources will execute them. For example, looks like ENTRY to a proc-handle will be a no-op, even if the proc-handle has a ON ENTRY OF proc-handle PERSISTENT RUN.
  • user-defined events like U1, U2, etc
  • key events like a, b, c
  • widget-level events like ENTRY, LEAVE, CHOOSE, VALUE-CHANGED, etc
  • anything else I'm missing
  • widget state can be not-realized, realized, visible, sensitive.

Automation can be tested in batch mode. In interactive mode, is more complex.

Also available in: Atom PDF