Consultor Eletrônico

Fixing WAIT-FOR errors 4123 4124 3269 (WAIT-FOR terminated)


There are a number of WAIT-FOR errors that users might encounter
when running their GUI programs. These include:

"None of the widgets used in WAIT-FOR statement are SENSITIVE.
WAIT-FOR terminated. (4123)"

"WAIT-FOR statement is not waiting for any event in the active
dialog box. (4124)"

"Run-time error in WAIT-FOR at line <n> (relative to expanded
source) of <filename>. (3269)"

The most common cause of these errors is that the developer is
working in the UIB (or in code similar to that generated by the UIB)
and is using an UPDATE statement with database fields, along with
a WAIT-FOR statement.

This is why one of the first things we ask when someone
reports these errors is whether they're updating records in the UIB
by adding code such as the following in the Main Block:

FIND FIRST customer.
UPDATE customer.name WITH FRAME frame-a.


If this is not what you're doing in your particular case, you should
still look closely at your code to see how you might be using the
UPDATE statement with WAIT-FORs. These errors rarely come up except
as the result of conflict between UPDATE and WAIT-FOR.

The main reason for the errors is that the UPDATE itself includes an
implicit WAIT-FOR, since by definition it sits there waiting
for the user to input data. This use of UPDATE runs counter to the
event-driven programming philosophy. In a proper event-driven design
you should never force a user to finish with any one field before
allowing him/her to go on to another one (as UPDATE implicitely does.)
Event-driven programming means allowing a user to click on any field
at any time, in any order -- unlike what we were accustomed to in
Version 6.

What happens when you use UPDATE as above is that once the UPDATE
is satisfied, the window (or frame) is likely to be dismissed auto-
matically. In the next instant, when the program reaches a statement
such as WAIT-FOR WINDOW-CLOSE or WAIT-FOR GO OF FRAME, the window or
frame is already gone -- hence the error message.

Eliminating this error requires a different programming approach --
an approach developed partly to be consistent with other apps
written in the MS-Windows and Motif environments, but one which also
makes more sense when writing apps for users who are accustomer to
working with other applications besides Progress in the GUI world.

(NOTE: This is not considered to be a workaround, since that term
implies a bug. The problem in this case is programming strategy.)

Instead of using an UPDATE statement, do the following:

(1) ENABLE the fields that you wish to update. The UIB automatically
creates an ENABLE statement for any database field you place on
the interface.

(2) Add an "Ok" ("Save") button and "Cancel" button to the interface.

(3) In the CHOOSE trigger for the "Ok" button, do an ASSIGN of the
fields that you've placed on the interface. As part of this
trigger block you may also want to apply whatever event the
main WAIT-FOR is waiting for. For example, if your Main Block is
waiting for WINDOW-CLOSE OF CURRENT-WINDOW:

ON CHOOSE OF btn_Save IN FRAME frame-a DO:
ASSIGN customer.name.
APPLY "WINDOW-CLOSE" TO CURRENT-WINDOW.
END.


(4) Define the "Cancel" button as AUTO-ENDKEY in its Property Sheet.
This will insure that when the user selects "Cancel" the
transaction associated with the window is backed out.

(5) Perform data validation in a schema trigger or use the
CHOOSE trigger for the "Ok" button to implement validation.
The bonus with the latter approach is that you can program the
procedure to APPLY "ENTRY" to any widget where invalid data is
detected, perhaps even changing the background and foreground
colors of the widget to give a visual cue to the user along with
an error message.


The most important part of this is using the combination of ENABLE,
WAIT-FOR, and ASSIGN instead of the UPDATE. The UPDATE statement
should be used only carefully, since its properties of field-level
validation run counter to style rules developed by GUI vendors. Once
the proper programming approach is implemented, WAIT-FOR errors will
be a thing of the past.

Progress Software Technical Support Note # 13784