Power-Programmierung/CD1.mdf/pascal/library/dos/database/edit_22/editor.doc

Text File | 1988-06-11 | 23.6 KB | 499 lines

                             Data Entry Editor


One of the most important things in applications program development is the
actual data entry itself.  Data entry would appear to be the simplest part
of any applications project on the surface, yet almost every programmer has
sweated and worried about the actual procedures, seemingly all out of propor-
tion to the task at hand.

Over the last few years, numerous magazine articles, indeed entire chapters
in computer programming texts, have been devoted to the importance of accurate
and efficient data entry.  But with all the stress on its importance, little
has been said about the methodology itself, leaving that to the programmer
or analyst to determine.


                          Data Entry Methodology

Data entry collects three basic types of data: character strings, whole
(integer) numbers and real (decimal) numbers.

Character strings are comprised of a group of alphabetic and/or numeric
characters, with the alphabetic characters in either upper, lower or mixed
case and are entered from left to right (left justified).  Whole numbers
(integers) are comprised of numeric characters and, unlike the Roman influenced
alphabetic characters, are derived from the Arabic right to left (or right
justified) notation.  The historically more recent decimal notation shares
both influences with the integer portion of the number right justified and
the decimal portion left justified.

As you can see, simply manipulating each of the three principal data types
can be considerably confusing for data input procedures.  For instance,
entering the integer value "123" should appear on the data entry screen as:

              0 the default "mask",
              1 the first character entered,
             12 the second character entered,
            123 the third character entered.

Note that the entry stays right justified; that is, each numeric character
entered "pushes" the preceding character(s) leftward, leaving the most
recently entered character in the rightmost column.

Decimal values are a bit more complex.  As shown below, the integer values
must remain right justified, while the decimal values are left justified
expanding from the decimal position rightward.  Thus, the value "123.45"
should appear on the entry screen as:

              0.00 the default "mask",
              1.00 the first character entered,
             12.00 the second character entered,
            123.00 the third character entered,
            123.40 decimal is toggled and the fourth character entered,
            123.45 the fifth character entered.

Note that the decimal must be "toggled"; that is, the decimal or "." key
must be pressed to signal the beginning of the decimal portion of the numeric
entry or the integer portion must be entirely filled.

In comparison, alpha-numeric entries (strings) would seem quite simple and
straight-forward.  But are they?  Depending on the needs of the data input
operator, alpha-numeric entries can be quite complex, particularly when
upper case alphabetic characters, numeric characters and lower case characters
must be mixed in a specific order.  For example, a part number could require
the first two characters of the field be numeric, the third character to be
upper case alphabetic, and the balance of the part number to be numeric as
shown below:

            12B34567 the part number,
            ||______ numeric characters only,
              |_____ uppercase alphabetic,
               ||||| numeric characters only.

By using a "mask", the data entry could readily provide character-by-character
editing to ensure that the numeric values are placed in a specific position
within the field and that the alphabetic character is an upper case character,
regardless if the shift key is pressed (thus saving a keystroke for the
input operator).

Using the "#" character to indicate a numeric character and "U" to indicate
an upper case alphabetic character the mask would appear thus: "##U#####".
If an alphabetic character was input into the numeric portion of the part
number, a tone would sound, indicating to the input operator that an error
had occurred and allow the input operator to make the correction before
continuing.

                           Using the EDITOR.TPU

Data entry normally requires more than one data field be entered.  While the
screen design and field placement is left to the programmer or analyst, the
EDITOR.TPU makes the placement and field length fairly easy to determine.
This version of EDITOR.TPU is fairly simplistic in that it is not ABSOLUTELY
"bulletproof" and allows numeric entry into an alphabetic position within
the field; however, this TPU will suffice for about 95% of all data entry
needs (see "Registration Note" at the end).

                           DATA ENTRY PROCEDURES

Five basic procedures are called from the TPU: EditDate(), EditString(),
EditInt(), EditReal() and EditChoice().  However, to use more than one
field, the variables "FieldNo" and "LastField" must be initialized in the
originating program and handled on a "Case" basis as noted below:


{$V-}                                    { Turn off string checking }

Var                                      { Program global declarations }
  Var1    : String[5];
  Var2    : Real;
  Var3    : LongInt;
  Var4    : String[8];
  Var5    : String[1];

Procedure GetEntry;
Begin
  FieldNo := 1;                          { Set beginning field }
  LastField := 5;                        { Set last field number }
  Var1    := '';                         { Initialize String value }
  Var2    := 0;                          { Initialize LongInt value }
  Var3    := 0.0;                        { Initialize Real value }
  Var4    := '  /  /';                   { Initialize Date }
  Var5    := '';
  Var6    := '';
  Repeat
    Case FieldNo of
      1 : EditString(Var1,5,5,2,15,0,'     '); { String }
      2 : EditReal(Var2,6,5,7,2,15,0);         { Real Number }
      3 : EditInt(Var3,5,5,9,15,0);            { LongInt }
      4 : EditDate(Var4,5,11,15,0);            { Date }
      5 : EditChoice(Var5,5,13,'Y','N',15,0);  { Choice 'Y/N' }
    End; { Case }
  Until FieldNo > LastField;
         { if the operator "bails out" }
  If Escape then
  Begin
    gotoXY(30,25);
    Write('Save current record (Y/N)? ');
    EditChoice(Var6,58,25,'Y','N',14,0);
  End;
  If (not Escape) or ((Escape) and (Var6 = 'Y')) then
  Begin
    (* data, record and/or file handling procedure(s) *)
                           .
                           .
  End;
End; { Procedure }


The apparently simple procedure shown above covers considerable complexity
within the EDITOR.TPU.  Three basic entry types are given: String, Real and
LongInt (Var1, Var2 and Var3).  Note that Var2 *MUST* be declared as LongInt.

                               STRING INPUT

The EditString() procedure is declared as follows:

        GetStr(Variable name,
                       Field length,
                       X position,
                       Y position,
                       Foreground color,
                       Background color,
                       Input mask);

The variable name is self-explanatory.  Field length should be declared as
the size of the variable string and, although it can be either longer or
shorter than the declared string length, the declared variable string length
(String[n];) will be the actual data size and will either expand or truncate
the input data.

The X and Y positions are equivalent to the Turbo Pascal "gotoXY()" statement
and positions the first character in the entry field on the data entry
screen.  A certain amount of caution should be used with windows in that the
window values may be different than the default "Window(1,1,80,25)".

The input mask, when used, may show "U", "#", "*" or spaces.  The placement
of each masking character is important in that the characters input from the
keyboard will follow the mask rules explicitly.  The String mask may be
merely spaces, indicating that any normal keyboard entry (excluding <Ctrl>
and <Alt> characters) are allowable.  The "U" character in the mask will
change the input character to upper case where applicable.  The "#" character
in the mask requires a numeric key to be pressed before any further data
entry will be continued.  If an alphabetic character is attempted in this
mask position, a tone or "beep" will sound and the cursor will remain in
position until a numeric key is pressed.

The "*" character in the edit mask is used as a "jump-over" character allowing
fields such as telephone and Social Security numbers to be entered without
having to enter the "-" character.  The character(s) that will actually
appear in the field MUST be declared in the field initialization.  Note also
that use of the "jump-over" character imposes certain field editing restric-
tions.  (See "Field Editing")

For example:

'UU###' will reformat the first two entered characters to upper case,
        and require that the last three characters be entered as numeric
        characters.

'UU   ' will reformat the first two entered characters to upper case and
        allow any succeeding characters following except <Ctrl> and <Alt>
        characters.

'     ' allows any characters except <Ctrl> and <Alt> characters for the full
        length of the field.

' U   '    forces the second character to upper case and allows the first,
        third, fourth and fifth characters in the field to be any character
        except <Ctrl> and <Alt> characters.

' *   ' allows any character in the first position, "jumps over" the
        second position, and allows any characters in the third, fourth
        and fifth position.

Remember that using the "#" character in the mask creates a "demand" entry
in that only numeric characters can be entered before data entry can continue.


                               NUMERIC INPUT

The EditInt() procedure is declared as follows:

         EditInt(Variable name,
              Field length,
              X position,
              Y position,
              Foreground color,
                 Background color);

The variable name, field length, X position and Y position are the same as
the EditString() procedure.  However, unlike the EditString() procedure, no
field mask is required.  Instead, the actual value of the integer will be
displayed and the integer value of the variable is returned.  The integer
variable must always be declared as a LongInt, regardless of its actual
value, and allows signed values of -2,147,483,648 to 2,147,483,647.  Values
larger or smaller than this must be of Type "Real" and entered using the
EditReal() procedure with 0 decimal places declared.  If a signed value is
to be entered, remember to allow an additional space for the sign in the
field length declaration.


The EditReal() procedure is declared as follows:

        EditReal(Variable Name,
                   Field length,
                   X position,
                   Y position,
                   Decimal position(s),
                   Foreground color,
                   Background color);

The EditReal() procedure is identical to the EditInt() procedure except for
the addition of the decimal position declaration.  The variable must be
declared as Type "Real" which allows for up to 11 or 12 decimal places
(depending on the size of the integer range) and allows for signed values.
As above, allow spaces in the field length declaration for both the sign (if
it is used) AND the implied decimal in this field.

Because numeric values are handled as strings during the actual input process,
care must be made to ensure the field length is long enough for the input
value.  For instance the input value "123.45" would have a field length of 6
to include the implied decimal character, rather than 5 for the five numeric
characters.  Note that once the integer portion of the number is filled, the
cursor will automatically position itself in the decimal entry position.

Note also that only numeric characters can be entered.  Any non-numeric char-
acter will cause a tone or "beep" to occur.

                             OTHER DATA TYPES

Two additional data "types" are also defined - dates and binary "choices".

The EditDate() procedure is declared as follows:

          EditDate(Variable name,
                   X position,
                   Y position,
                   Foreground color,
                   Background color);

The EditDate() procedure returns an 8-character string and MUST be initialized
with the "/" characters in the appropriate position; that is, the third and
sixth character of the string (for instance: Date := '  /  /';).  Because of
the wide range and complexity of date handling processes, no attempt at date
verification is presented in the TPU, but instead is left to the programmer/-
analyst for verification on completion of the field entry.

While the EditDate() procedure was initially intended as a "MM/DD/YY" entry
field, it can work equally as well as a "YY/MM/DD" or "DD/MM/YY" field,
allowing for military and European date styles.  Note that extended dates
such as "MM/DD/YYYY" can also be handled with "jump-over" characters in the
EditString() procedure.


The EditChoice() procedure is declared as follows:

          EditChoice(Variable name,
                     X position,
                     Y position,
                     Choice1 character,
                     Choice2 character,
                     Foreground color,
                     Background color);

The EditChoice() procedure returns a single byte and need not be initialized,
although it is good programming practice to do so.

This procedure allows for a binary choice (one of two possibilities) such as
"T/F" (true/false), "Y/N" (yes/no), "M/F" (male/female), "+/-" (plus/minus)
and the like.

                           DEFAULT FIELD VALUES

In all procedures, default values may be declared by initializing the appro-
priate variable equal to a specified value before the data entry is actually
accomplished.  Field values may contain specific default values to minimize
input operator keystrokes.  The "current date" field is a good example of a
default field value that may be overwritten by the input operator.  In
this case, the date field defaults to the current date string if the input
operator does not choose to edit that particular field.

Field defaults help to minimize input keystrokes and entry errors by providing
a given value that may be accepted or changed as required.  However, choosing
specific default values may be more difficult for the programmer or analyst.

A general rule of thumb is: 1) if the default value occurs less than a third
of the time, omit the default value; 2) if the default value occurs between
a third and half of the time, check with the input operator or analyst to
determine the "comfort level" of data entry; and 3) if the default value
occurs more than half the time, include the default value in the display.

While these rules are not "hard and fast", they provide a quick method of
determining default field values.  Realize also that every application has
requirements and nuances that may not be readily apparent when preparing the
initial prototype or design.  Further changes to the program(s) may be
needed to maximize efficiency and improve input operator comfort.

                     MULTIPLE FIELD ENTRY AND EDITING

Under normal circumstances, data entry requires that more than one field be
entered on the data entry screen.  Provisions must be made to correct data
entry errors either when they occur or at a later time in the process, or
when existing data must be updated.

Good programming practice would require both "new" data entry and "edit"
procedures to allow the input operator the choice of either editing existing
data or adding new data to the data file.

The program example above serves as an example of "new" data entry.  The
values of Var1 and Var5 are set to null (Var1 := '';) and the values of Var2
and Var3 are set to 0 and 0.0, respectively and Var4 is set to '  /  /'.  To
edit an existing record, merely alter the initializing statements to equal
the selected record fields (i.e., "Var1 := Rec.XVar1").

Multiple Fields

In both the new entry and edit procedures, the variables "FieldNo" and
"LastField" must be initialized.  In cases where there is only one field to
be entered, these variables need not be declared. (See EDITDEMO.PAS.)

"FieldNo" must be initialized to the starting field number.  Note that the
starting field number need not necessarily be the first mandatory declared
field number (number 1).  While the number of fields on the entry screen is
essentially unlimited (2+ billion fields), the screen size itself will
impose limitations on the number of fields available for use.  A caveat: the
first declared field MUST be number 1!

Using both the "Repeat" and "Case" statements allow for considerable flexi-
bility in changing fields:

    PgUp        goes to the first declared field. (FieldNo 1)
    PgDn        goes to the last declared field.  (LastField)
    Up arrow    goes to the previous field.
    Dn arrow    goes to the next field.
        Enter           goes to the next field.


Field Editing

In essence, EditString() field editing is based on normal word processing
and editing techniques.  They are:

        Right arrow   Moves the cursor one position right in the field.
        Left arrow    Moves the cursor one position left in the field.
        Home          Goes to the first character of the field.
       *Del           Deletes the character directly above the cursor.
       *Backspace     Deletes the character to the left of the cursor.
       *Ins           Toggles between "insert" and "overwrite" modes in the
                      EditString() procedure.  The default is "overwrite", but
                      pressing the <Ins> key allows characters to be inserted
                      and forces the following characters to fill the field.
                      Note that characters forced beyond the end of the field
                      are lost and that changing fields resets the toggle to
                      the "overwrite" mode.

   * Note:  These keys are invalid if the EditString() field contains a
            "jump-over" character to avoid deletion or misplacement of the
            default character.

String and numeric editing procedures have somewhat different editing facili-
ties due to the intrinsic differences in string manipulation.  Editing a
numeric field requires that the <Del> key be pressed until the offending
character (and the following or preceding characters) of the field are
deleted and then re-entered correctly.  Toggling the decimal or "." key
provides the same situation in real number editing, only from the left side
of the decimal position.

                       "ESCAPING" THE DATA ENTRY PROCEDURE

Under certain circumstances, the input operator may wish to exit the data
entry procedure without saving the current record.  The globally declared
Boolean operator "Escape" is set to "True" if the operator presses the <Esc>
key at any time during the data entry process.

NOTE: Care MUST be taken to ensure that the current record can be accepted
      or discarded at the operator's discretion.  This can easily be done by
      querying the operator "Save current record (Y/N)?" at the bottom of
      the data entry screen when the escape key is pressed.  See the example
      provided above (DATA ENTRY PROCEDURES).


                             GENERAL COMMENTS

For some unknown reason, data input and editing is one of the least supported
areas in the computer programming field and is generally relegated to various
"off-the-shelf" data entry products.  While I can hardly fault the software
houses for providing for this need, I am continually astounded by the various
"standards" espoused for data entry.

For instance, a number of well known and highly successful "database" programs
do not provide the input operator error feedback until the field entry (or
the entire screen!) is completed.  Some require the deletion and total
re-entry of the field, while others have such poor editing methods that it
is frequently simpler and faster to delete the entire record and re-enter it
as a new record.

Data entry is an innately boring and repetitious job, but it is THE MOST
IMPORTANT part of data collection.  Without accurate and efficient data
entry, even the best system in the world is little more than a pile of
electronic equipment with some interesting (and unusable) software residing
on disk or in memory.

EDITOR.TPU does not attempt to impose a "standard", but simply takes advantage
of the IBM keyboard to allow the data entry operator to use it as though it
were a typewriter keyboard.  We must remember that data entry operators are
basically typists, and the best are VERY FAST typists.  EDITOR.TPU attempts
to provide maximum programming flexibility, ease of editing and simplicity
of data entry.

Speed and accuracy is the goal of data entry.  It is the responsibility of
the programmer and analyst to ensure that this goal is met - not the data
entry operator.  If there is EVER any doubt about the best method of data
entry, ask the input operator (not necessarily the supervisor) what the
easiest method would be.  Few data input operators realize they have any
choices in input methods and this small effort can make you a star player in
your field!

At the same time, input screen design is of major importance.  If color is
used, make sure that the colors are complementary and easy on the eyes.
Bright colors and flashing characters may impress the boss, but will drive
an input operator up the wall in minutes.  When in doubt, ask the input
operator or, better yet, allow the operator a choice of screen colors.

Data input usually is from a paper form to an input screen.  Whenever possible,
have the input screen match the paper form as closely as possible.  This
allows the input operator to glance up at the screen and back to the form
without losing his/her place.  If the screen design simply cannot be matched
to the form, take a long look a redesigning the form.  Speed and accuracy
means profits, and few managers will resist an increase in speed and accuracy
over the relatively minor nuisance of redesigning a potentially confusing form.

                             REGISTRATION NOTE

EDITOR.TPU and the associated documentation and demonstration program are
yours to use as you see fit.  However, if you plan to copy and distribute
the program suite, please distribute ALL of it.  EDITOR.TPU is marketed on
the shareware concept, "If you like it, buy it; otherwise, pass it on."

If you intend to use EDITOR.TPU in your programs (or you're already using
it), please register your copy!  If you use EDITOR.TPU in only a SINGLE
program, the savings in development time and effort are far more than the
small $15.00 registration fee.  The registration fee is only intended to
cover the cost of duplication and mailing and to determine the amount of
interest in personal computer data entry methods.

As of this date, an improved BULLETPROOF version of the EDITOR.TPU is in the
works.  This version may not be available on BBSs in the future; however, it
WILL be available to registered users.

If you have questions or comments (or wish to register), please address them
to:

                             COMPUsystems N.W.
                             Attn: John Winney
                        9792 Edmonds Way, Suite 226
                             Edmonds, WA 98020
                              [phone]
C/O George Wishart [70165,460]