Home page  
Help >
Special Procedures
Version 7.11
Special Procedures

What makes them Special? How are Special procedures different from regular procedures?

Special Procedures are different from regular procedures in two ways:

Special Procedures are active only when a Screen or a Dialog is up.
That is, they are invoked (or triggered) by various methods when
you are in APPEND , UPDATE , READ , LOOK , SCROLL , or DIALOG mode
and a screen or a dialog is instantiated. As such, they can address
named objects and/or fields that are on these screens or dialogs.

There are several commands that do not have any meaning in regular
procedures since they address named objects that are only available
when the screen or dialog that contains them is present. So these
commands can only be used in Special procedures. They are:

CURSOR SCREENSTATUS
FUNCTION SCREENPRINT
REJECT SCROLL
SELECT MOVE (some forms)
BOLD DIM (some forms)
UNBOLD UNDIM (some forms)

Special Procedures are created like any other procedure, via DEFINE and REDEF. Special Procedures are used to derive values for other fields on the screen, to pass messages between the user and the screen, to drill down on fields, to pass control to nested screens, to control cursor movement, to perform validations not otherwise provided for, etc.

How are Special Procedures invoked?

Special Procedures that are attached to buttons on the screen are
invoked when the user presses the button.

Special Procedures that are attached to fields on the screen can be
set to trigger under any or all of the following events:

- when the cursor enters the field
- when the cursor leaves the field
- if the user double-clicks or right-clicks on the field

Special Procedures that are attached to the screen itself can be set
to trigger under any or all of the following events:

- at the beginning of each record
- at the end of each record
- one time only when the screen is first presented
- if the user double or right-clicks on any field in the record
- if the user shift-clicks on any record
- when the screen does an auto-refresh


Special Procedures Attached to Buttons

In the button properties for every button you drop onto the screen there is a slot where you can specify a procedure name. Just enter the name of the SP to execute if this button is pressed.

Special Procedures Attached to Fields in the Screen

In the Field Services properties for every field on the screen there are three slots where you can specify Special Procedures. One is for an "entry" SP, another for an "exit" SP, and the third is for a "double-click" SP. Just enter the name of the SP in the appropriate slot.

In general, "exit" SPs execute after the user has entered data into the field and after all other assigned validations have passed. An "entry" SP executes before the user enters data into the field. A "double-click" SP executes if the user double-clicks or right-clicks on this field.

The default rules for execution of field-attached SPs are:

An "exit" Special Procedure executes unconditionally in APPEND mode
when the cursor leaves the field for the first time. After that, it
executes only if something is entered into the field. It does not execute
if the user does not change the content of the field.

An "entry" Special Procedure executes unconditionally when the cursor
first visits the field in APPEND mode. After that, it will execute only if
the user presses the control to the side of the field or presses F5. This
is useful for SPs that are popping up LISTPICKS for the user.

You can override these defaults and declare that either or both types of SP are to execute unconditionally (every time) by placing an asterisk * in front of the SP name in the properties box. For Example, if you want an entry SP to capture the value in a field before the user has a chance to modify it, place an asterisk * in front of the "entry" SP name.


Special Procedures Attached to the Screen Commands

The APPEND, UPDATE, SCROLL, READ, and LOOK commands allow Special Procedures to be specified as part of the command syntax. They are invoked at certain times during screen input, update, or display operations and provide the means to customize these operations to specific applications.

The following specifcations dictate when the Special Procedure is to be executed:

-F spname The "First-Time-Only" option. Execute the SP "spname"
just before the first record is presented, and not again.

-B spname The "Beginning-of-Each-Record" option. Execute the SP
"spname" as each record is presented, and before the
user has done anything.

-E spname The "End-of-Each-Record" option. Execute the SP "spname"
after the user has filled in the last field (or pressed OK)
and before the record is written.

-S spname The "Record-Has-Been-Selected" option. Execute the SP
"spname" if the user shift-clicks this record.

-D spname The "Double-Click" option. Execute the SP "spname" if the
user double-clicks or right-clicks on any field in the record.

-R spname The "Auto-Refresh" option. Execute the SP "spname" if the
screen has done an auto refresh. The screen does an auto
refresh if the user has sorted the records (via the SORT
power button) being displayed, or if the subset in the
collection being displayed was changed by some other SP.

One or all of these specifications can be added to the normal command syntax just after the screen name. For example:

UPDATE A CUSTOMERS CUST -B SP_LIGHT

The custom screen named CUST was invoked to view and/or alter a subset of CUSTOMERS records. The Special Procedure named "sp_light" is executed as each record is presented on the screen.

Copyright © 2019 , WhamTech, Inc.  All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. Names may be trademarks of their respective owners.