The context of a block generally lies within the code defined by the beginning and end of the block. For an external procedure, the block beginning and end is the first and last statement in the file. For any other block, it is the block's header and END statement. The context of an external procedure includes all SpeedScript data, objects, triggers, and internal procedures that it defines. This is the only type of block that can define both trigger and internal procedure blocks within its context. Thus, the external procedure context is often called the main block of the procedure. For example, the variable, balance-sum, is defined in the main block of sample3 and can be modified by all statements and blocks defined within sample3.
Note: A SpeedScript trigger is a statement or block of code that executes in response to a SpeedScript event and is usually specified with an ON statement. SpeedScript events have limited but important uses in WebSpeed. They are identified by event keywords that include WEB-NOTIFY, CLOSE, and several database events. For more information on the ON statement and other trigger statements, see OpenEdge Getting Started: ABL Essentials or the OpenEdge Development: ABL Reference.
In general, any data or objects that you define within the context of a procedure are available only to the statements of that procedure. However, any data or objects that you define within other types of blocks are actually part of the nearest enclosing procedure context, not the context of the block where they are defined.
For example, this procedure calculates the sum of customer balances using a variable fBalance, defined within a FOR block:
sample3
FOR EACH Customer FIELDS (Balance) NO-LOCK:
DEFINE VARIABLE fBalance AS DECIMAL NO-UNDO. fBalance = fBalance + Customer.Balance.
END.
{&OUT} "<P>" "Corporate Receivables Owed:"
STRING(fBalance, "$>,>>>,>>>,>>9.99") "</P>" .
However, fBalance is actually assigned to the outer procedure context, so the {&OUT} statement, outside the FOR block, can also reference it.
Variable definitions are always assigned to the nearest enclosing procedure or trigger context, because WebSpeed maintains the run-time values for variables in a single stack frame for the entire procedure. Thus, when a procedure A calls another procedure B, all of procedure A's variable values are saved for the return from procedure B. However, when WebSpeed executes a DO, FOR, or other type of block, no prior variable values are saved before the block executes. Likewise, there is no separate data context to maintain variables defined within these blocks. Therefore, WebSpeed maintains the variables defined within these blocks as though they were defined directly in the procedure context.
