Kbase 14094: Perils of UPDATE & WAIT-FOR (also, errors 4123 4124 3269 )
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Perils of UPDATE & WAIT-FOR (also, errors 4123 4124 3269 )
One example of a Version 6 programming technique which can lead to
problems in event-driven procedures is the UPDATE statement.
In PROGRESS Version 6, the UPDATE statement is used to present
database fields or variables to the user so that their values can
be changed.
One default feature of the UPDATE statement is that it blocks for
input on each field or variable, in effect behaving like a wait-for
condition at the field level. While a particular variable or field
is being updated, a user is not allowed to continue through the
interface until a value has been input. (In some cases this value
may be blank, or a default value provided by the program or database.)
The UPDATE statement's input-blocking behavior is widely used by
Version 6 programmers to implement data validation at the instant
that data is entered. If a new value does not satisfy the database
or application requirements, a message can be presented to the user
explaining what kind of value should be entered instead. Program
execution does not continue until this condition is met. Users
are required to remain in a given field or variable until its
validation criteria are met.
While this technique is practical for procedure-driven programs
such as those developed in Version 6, the UPDATE statement's
blocking properties can cause problems in the event-driven world.
One reason is the expectation by users of GUI programs that an
application will not restrict navigation through an interface at the
widget level -- validation should be carried out only when the user
has signaled readiness by applying a "Save" event of some kind.
Programmers in Version 7 who insist on implementing field-level
validation therefore risk violating the accepted style rules of the
native windowing environment. They also risk confusing experienced
users in that environment who are not accustomed to the counter-
intuitive behavior.
A more serious problem can arise when a WAIT-FOR statement is used
in combination with one or more UPDATE statements. The problem
arises due to another property of the UPDATE statement: that once
its last referenced field or variable has been successfully updated
by the user, PROGRESS will automatically dismiss its associated
frame before continuing to the next statement. This results in
runtime errors when the WAIT-FOR statement is reached and PROGRESS
detects that the referenced frame or window no longer exists.
For example, the following code fragment results in a runtime
"WAIT-FOR terminated" error in PROGRESS:
DEF VAR x AS CHAR.
DEF VAR y AS CHAR.
DEF FRAME f x y WITH VIEW-AS DIALOG-BOX.
UPDATE x y WITH FRAME f.
WAIT-FOR "GO" OF FRAME f.
Completion of the UPDATE statement dismisses frame f immediately.
Once this frame is gone, the subsquent WAIT-FOR statement is unable
to reference it. PROGRESS automatically terminates the WAIT-FOR
and presents an error message to the user.
If an UPDATE statement must be used in event-driven programming,
any WAIT-FOR statement that references the same frame as that used
in the UPDATE should be eliminated, allowing the field-level blocking
properties of the UPDATE to serve as the frame-level wait-for:
DEF VAR x AS CHAR.
DEF VAR y AS CHAR.
DEF FRAME f x y WITH VIEW-AS DIALOG-BOX.
UPDATE x y WITH FRAME f.
Note that the only difference between this code fragment and the
previous one is that the WAIT-FOR statement has been deleted.
By including VIEW-AS DIALOG-BOX in the DEFINE FRAME statement,
the default "GO" that is applied by PROGRESS upon completion of the
UPDATE is also processed as a "GO" that dismisses the entire frame.
Since this is accomplished within a single statement, there is no
runtime error due to a frame or window disappearing before another
statement references it.
Progress Software Technical Support Note # 14094