Progress
Programming
Handbook
Using Editing Blocks and User Interface Triggers
This procedure uses an editing block to enable a special key while allowing normal data entry:
This procedure uses an EDITING block on the UPDATE statement. This means that the EDITING block processes every keystroke the user enters while that UPDATE statement is executing. Within the EDITING block, the READKEY statement reads a keystroke from the user. The associated key code is automatically stored as LASTKEY. The procedure uses LASTKEY and the FRAME–FIELD function to determine whether the key is F6, and whether it was entered from within the Sales–rep field. If so, it displays a list of all known sales reps. If the key is not F6, or the current field is not the Sales–rep field, then the APPLY statement is executed. This causes Progress to handle the keystroke normally.
This procedure uses a user interface trigger in place of the EDITING block to achieve the same functionality:
Use a trigger in place of the EDITING block to produce simpler, cleaner code. It would be easier to rewrite this code to be more event driven. First, replace the UPDATE statement with ENABLE, WAIT–FOR, and ASSIGN. You then might remove the REPEAT block and define a button that the user can select to move to the next Customer record. You might also replace the display of sales reps with a selection list or browse widget.
The following procedure uses an EDITING block to disallow normal data entry on a field and allow only a special key:
Like
p-kystka.p
, this procedure uses an EDITING block on the UPDATE statement. In the EDITING block, it uses READKEY, LASTKEY, and FRAME–FIELD to obtain and analyze a keystroke. If the keystroke is not in the Sales–rep field, it is processed normally. Within the Sales–rep field, only the spacebar is treated specially and only the TAB, BACK–TAB, GO, and END–ERROR key functions are treated normally. If the user types any other key within the field, the terminal bell sounds. When the user presses the spacebar in the Sales–rep field, the value of that field and the Sales–region field change.The following procedure uses triggers to accomplish the same thing:
Note the use of RETURN NO–APPLY in both the ANY–PRINTABLE and spacebar trigger. This is equivalent to omitting the APPLY LASTKEY statement in an EDITING block. Thus, the spacebar trigger brings the next Sales–rep into view, without also inserting a space character in the field.
Note also that in
p-kystk2.p
the ANY–PRINTABLE trigger rejects all keys that enter data characters other than a space. This works together with the spacebar trigger to allow only the spacebar and navigation keys (TAB, etc.) in the field.Sometimes an EDITING block defines a special key that applies for all active fields:
In
p-kystk3.p
, the EDITING block defines a special key, F6, that is available in all fields of the UPDATE statement. When the user presses this key, the previous Customer record displays.The following procedure uses a trigger to achieve the same result:
If you define a trigger to be active ANYWHERE, then it applies to all widgets. In
p-kystk4.p
, the F6 trigger executes whenever the user presses F6 while input is enabled. Within the trigger, the FRAME–FIELD function determines whether the t rigger executes from the UPDATE or PROMPT–FOR statement. If it is the PROMPT–FOR statement, then F6 is ignored; if it is the UPDATE statement, the previous Customer record displays.NOTE: In a larger program, be careful of the scope of the ANYWHERE trigger. You are usually better off listing the specific widgets to which a trigger applies. For example, you could rewrite the ON statement inp-kystrk4.p
as follows:
If you take this approach, you can remove the code that checks whether FRAME–FIELD is Cust–num within the trigger.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |