Kbase 13425: user gets errors or no response with APPLY ENTRY to widget
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
user gets errors or no response with APPLY ENTRY to widget
In event-driven programming, it is common for users to wish to apply
focus to different widgets depending on a condition in the program or
data input into a field. The way to do this is with the APPLY ENTRY
statement:
APPLY "ENTRY" TO fill-in-1 IN FRAME f.
Two things can immediately be noted about the syntax in this
statement: first, the event being applied ("ENTRY") is enclosed in
quotes; and second, the statement includes a FRAME phrase.
The FRAME phrase is particularly important, since often PROGRESS will
*not* generate an error if it cannot find the frame context for the
widget you're applying the event to (a behavior which under certain
circumstances might be desirable, as when a widget and/or its frame
have been temporarily hidden.)
Other problems arise when APPLY ENTRY is used within a block of
trigger code. When trying to move focus to a widget that's not the
same as the one whose trigger is firing, you must be sure to include
a RETURN NO-APPLY statement after the APPLY ENTRY:
ON CHOOSE OF button-1 IN FRAME f DO:
/* some brilliant trigger code */
APPLY "ENTRY" TO fill-in-2 IN FRAME f.
RETURN NO-APPLY.
END.
Why is the RETURN NO-APPLY important? The best way to answer this
is by looking at what happens when it is left out. Ordinarily, when a
trigger block executes for a widget (such as "button-1" in the example
above), upon completion it returns focus to that widget. So, in the
above example, without the RETURN NO-APPLY, "button-1" will regain
focus after the CHOOSE trigger has finished executing.
Adding an APPLY ENTRY statement alone, without a RETURN NO-APPLY,
makes no difference. What happens is that the "ENTRY" event *does*
indeed get applied to the new widget, but in the next instant, when
the trigger block finishes executing, focus immediately jumps back
to "button-1", the original widget. This usually happens so quickly
that it appears that the APPLY ENTRY has been ignored altogether.
What the RETURN NO-APPLY does is tell PROGRESS *not* to bring focus
back to the original widget, effectively overriding the default
behavior just described. If you're trying to APPLY ENTRY within your
trigger code and not seeing any results, or if you are seeing peculiar
errors due to field formats, etc., then check to make sure you've
included a RETURN NO-APPLY statement in the trigger block, following
the APPLY ENTRY.
Progress Software Technical Support Note # 13425