. To make a memo window accessible, include the database alias in the
window list.

        If a window title contains a character that is not alphabetic, numeric
or an underscore, include the part of the title up to the first
character that is not alphabetic, numeric or an underscore in the window
list.  For example, if the window title is Client List, include Client
in the window list (the space between Client and List is not alphabetic,
numeric or an underscore).

        If a window title contains a character that is not alphabetic, numeric
or an underscore, you can place the title within quotes in the window
list.  For example, if the window title is Client List, you can include
"Client List" in the window list.

SHOW <expL3>
        The SHOW clause is executed whenever SHOW GETS is issued.  The value
returned by a SHOW routine is ignored.  A SHOW routine may be used to
refresh @ ... SAYs, or enable or disable GET objects.

VALID <expL4> | <expN1>
        When you attempt to exit the READ, the VALID clause is evaluated.  The
VALID clause may be a logical or numeric expression or a User-Defined
Function (UDF) that returns a logical or numeric value.

        If <expL4> evaluates true, the READ is terminated.  If VALID <expL4>
evaluates false, the cursor remains in the same field or the same GET
object is selected if possible.

        If the cursor cannot remain in the same GET field or the same GET
object cannot be selected (perhaps the VALID routine deactivated the GET
field or object), you are moved to the first GET object.

        If the VALID clause returns a number, you are moved to the
corresponding object.  If an object corresponding to the number doesn't
exist, the READ is terminated.  Returning a value that isn't of logical
or numeric type is identical to returning true (.T.).

WHEN <expL5>
        The WHEN clause determines if the READ is executed based on the result
of a logical expression.  The logical expression <expL5> must evaluate
to a logical true (.T.) when the READ is issued for the READ to be
executed.  If <expL5> evaluates to false (.F.), the READ command is
ignored and program execution continues with the command immediately
following the READ command.

OBJECT <expN2>
        You may specify which GET object is initially selected when a READ is
issued by including the OBJECT clause.  The value of <expN2> determines
which GET object is initially selected.  A GET object's number is
determined by the order in which the GETs are issued.

        Each individual push, radio and invisible button is considered an
object.  In the following program example a GET field and three radio
buttons are created.  The middle radio button is initially selected by
including the OBJECT 3 clause with the READ command.  The name GET field
is OBJECT 1, the first radio button is OBJECT 2, the second radio button
is OBJECT 3 and the last radio button is OBJECT 4.

        STORE 1 TO radio
        STORE SPACE(10) TO name
        CLEAR
        @ 2,2 SAY 'Enter a name: ' GET name
        @ 4,2 GET radio PICTURE '@*R Apples;Oranges;Lemons'
        READ CYCLE OBJECT 3

TIMEOUT <expN3>
        TIMEOUT is the length of time the READ is in effect.  <expN3>
determines how many seconds may elapse without user input before READ is
terminated.  If the READ is terminated by TIMEOUT, READKEY() will return
20 if changes have not been made to the current field.  If changes have
been made, READKEY() returns 276.

        When READ is terminated by a TIMEOUT, any changes made to the field
being edited when the TIMEOUT occurs are discarded.  However, changes
made to other fields are saved.

SAVE
        All GET statements are automatically cleared following READ unless the
SAVE keyword is included.  If you include SAVE, you can reissue READ
without reissuing the GETs.

NOMOUSE
        Including NOMOUSE prevents objects from being selected with the mouse.
You must use the keyboard to move from object to object.  You may still
use the mouse within fields to cut, copy, paste and position the cursor.

LOCK | NOLOCK
        The optional LOCK and NOLOCK keywords let you specify if the records
used in @ ... GETs during a READ are automatically locked in FoxPro/LAN,
the network version of FoxPro.

        If the LOCK keyword is included, record locks are attempted for every
record used in @ ... GETs.  If the locks are successfully placed, you
can edit the records.  SET REPROCESS determines how further record
locking attempts occur if even one of the records cannot be locked.  See
SET REPROCESS in this help facility for further information.  If LOCK or
NOLOCK is not included, READ defaults to READ LOCK.

        If the NOLOCK keyword is included, the records used in @ ... GETs are
not locked.  When NOLOCK is included, all @ ... GET fields are made
read-only.  If a field is used by a control (check box, popup, radio
button, etc.) the control is disabled (cannot be selected and is
displayed in the disabled colors).

        Any SHOW GETS (but not SHOW GET) commands issued during the READ
respect LOCK or NOLOCK.  For example, if READ or READ LOCK is issued,
all SHOW GETS attempt to lock the records involved in the READ.  If READ
NOLOCK is issued, SHOW GETS does not lock the records.  An the optional
LOCK keyword is available for SHOW GETS to override a READ NOLOCK.

        Records used in a READ can also be explicitly locked with RLOCK() or
SHOW GETS LOCK.  To unlock records used in a READ, use UNLOCK or lock
another record.

COLOR [<color pair list>]
        You can specify the color of the current GET object by including the
optional COLOR clause.  When an object is selected, it assumes the
colors of the second color pair in the color pair list.  All other
colors in the color pair list are ignored.  You can omit the first color
pair, but you must still include the comma.

COLOR SCHEME <expN4>
        If you include a COLOR SCHEME, color pair 2 of the specified color
scheme determines the color of the current field.  By default the color
of the current GET field is determined by color pair 2 of color scheme 1
(User Windows).  The color of GET objects are not affected by this color
clause.

Foundation READs
----------------

FoxPro 2.0 lets you easily create event-driven interfaces (like
FoxPro's) for your applications.  Enhancements to READ and READKEY(),
the addition of two new functions, WLAST() and WREAD(), and changes to
the window functions facilitate the creation of your own event driven
interface.  This section provides a suggested method for creating an
event-driven interface in FoxPro 2.0.

These changes do not affect any applications written in earlier versions
of FoxPro -- your older applications will perform as they always have.

In previous versions of FoxPro, some sophisticated users utilized an
event loop to handle menu choices and window selections when creating an
event-driven interface.  The event handler would constantly poll the
system status and then take action based on which window was on top or
which menu option was chosen.

In an event loop, DO WHILE is used to create the event loop (often a
large loop).  Event loops should be avoided for several reasons:

-       Event loops are constantly being executed, making them CPU hogs.

-       Event loops are complex and difficult to program.

-       Event loops are unfriendly in multi-programming environments like
DESQview, Windows and the Macintosh MultiFinder.

A Single READ with Multiple Windows
-----------------------------------

Improvements have been made to FoxPro 2.0 so that event loop programming
should rarely be required.  A single READ supporting multiple windows
can now be used to eliminate most event loops.  A single READ with
multiple windows provides versatility and flexibility without complex
programming.