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 = 
     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.