===========================================================================
USING EEPS
===========================================================================
PRODUCT: R:BASE VERSION: 4.5+ or Higher
===========================================================================
CATALOG: Forms, Reports & Labels AREA : Forms
===========================================================================
Many of the new form capabilities of 4.5 Plus! are centered around new
Entry/Exit procedure (EEP) commands and using EEPs to accomplish tasks not
available through form functions or expressions.
Using EEPs often means making separate edit and entry forms, particularly
when using the EEP only commands. Don't consider this a drawback, simply
copy the form and make the necessary changes, they are often very small.
The application will use one form or the other. It is often much easier
and quicker to separate the forms instead of trying to combine all
possible actions and situations into a single form.
Two simple rules you need to know when using EEPs:
Data is passed from the form to the EEP and vice versa through variables.
The data can be placed in variables through locating variables instead of
columns on the form. The data is then saved to the table by using a form
expression of the type colname = .varname.
Alternatively, the column is located on the form and data placed in a
variable through the use of a form expression of the type varname =
colname.
Which method you use depends on whether you are using the form with the
Enter command (Add data) or the Edit command (Edit data) as well as what
you need to accomplish with the EEP.
Variables can be placed on any table in the form. They do not need to be
placed for the same table the EEP is on. For example, you can place
linking column values into variables in expressions on table1. Table1
sets up these values and they are the same for every table in the form.
Also, a variable defined to pass or return a value from an EEP does not
need to be located on the form.
When editing data you will find it easier to place the columns on the form
and use form expressions to place the row data into variables for EEPs.
This lets the column values be directly editable by the user.
When the EEP is calculating a value to be returned to the form and loaded
into the table, locate the variable on the form and use RECALC or RECALC
VAR in the EEP.
You will see many examples in the other articles in this Exchange of
variables used to pass data to and from EEPs.
An EEP always executes.
Wherever you place an EEP, at the field level or at the table level, the
code will be processed when the specified event happens. When you place
an EEP on exit from a field, for example, it will execute when you leave
the field going forwards and when you leave the field going backwards.
When you place an EEP on exit from a row, it executes whenever you leave
the row with any keystroke -- going to another row, to another table, to
the menu -- all leave the row.
A key element of placing EEPs in forms is to make they execute when you
want them to, and keep them from executing at the wrong times. Sometimes
that means placing an EEP in the not quite logical place.
For example, an EEP placed After leaving section executes when you leave
that table - to change tables or to leave the form. But if you leave the
table by leaving the form (Exit on the form menu), the EEP code executes
after you press Enter on the Exit option. It's difficult to trap for the
[Enter] keystroke in an EEP because in so many places it is a valid
keystroke you want to be used to execute the EEP. Instead of placing the
EEP After leaving section, it may be placed On exit from a row or After
saving row.
Because an EEP always executes, EEPs frequently use the LASTKEY function
to check how the user caused the EEP to execute. This lets the developer
make the EEP execution conditional. All the code in the EEP does not
always execute; if certain keys are pressed, such as Esc, control is
immediately returned to the form.
Examples of using the LASTKEY function to control EEP execution are used
in many of the other articles in this issue.
Table level vs. field level EEPs
Where you place an EEP determines when it executes. Some experimentation
may be needed to get an EEP in the right place and trap for the right
keystrokes. There are no rules regarding placing an EEP at the table or
at the field level. Some seem to logically work better in one place or
the other. A form-in-a-form, for example, is usually called from a field
EEP. Summing rows or printing works well at the table level, After saving row.
A table level or row EEP is used when you want to perform actions after
all the data has been entered for a row, i.e. the row information is
complete. A field level EEP executes as data is entered in a single field.
Field level EEPs are more easily conditional than table level EEPs. Often,
an EEP can be run from either the field level or table level with only
small changes in the code.
Field level EEPs execute when you enter or exit a specific field. Since
users can move wherever they want on a form (using a mouse you don't
need to go through field by field) a field level EEP is not always
executed. A table level EEP is always executed. No matter where you
place it at the table level, that action will happen at least once when
using a form.
When trapping keystrokes in a table level EEP, put the EEP On exit from a
row instead of After saving row. After saving row executes after you
select from the menu. On exit from a row executes before you get to the
menu. After you select from the menu, the last keystroke is [Enter], not
the key the user pressed to get to the menu.