Kbase 33421: None of the widgets used in WAIT-FOR statement are SENSITIVE WAIT-FOR terminated. (4123)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Solution ID: P3421
FACT(s) (Environment):
Progress 9.1C
SYMPTOM(s):
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)
CAUSE:
The most common cause of these errors is that the developer is working in the AppBuilder (or in code similar to that generated by the AppBuilder) 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 AppBuilder 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 implicitly does.)
Event-driven programming means allowing a user to click on any field at any time, in any order.
What happens when you use UPDATE as above is that once the UPDATE is satisfied, the window (or frame) is likely to be dismissed automatically. 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, but one which also makes more sense when writing apps for users who are accustom to working with other applications besides Progress in the GUI world.
FIX:
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.