                         WELCOME TO PARADOX 6.0
                         ----------------------

    This file contains important information which is not contained in the
    documentation for Paradox 6.0a! Read this file in its entirety. All
    information in this file supercedes information in the Paradox 6.0
    documentation.


Table of Contents

    1. Installation Notes 
    2. Compatibility with Paradox 2.0
    3. Form Design 
    4. Multitable Forms 
    5. DataEntry/KeepEntry and MultiEntry/KeepEntry 
    6. Graphs 
    7. PAL 
    8. Tools/More/Subtract
    9. Paradox Utilities
   10. Data Entry Toolkit


1. Installation Notes
---------------------

    INSTALL on the Installation/Sample Tables disk will install Paradox on a
    hard disk or network.  The installation procedure for a  hard disk is
    described in the Introduction manual.  For more  information on network
    installation see the Network Administrator's Guide.
  

Installing on an IBM PS/2 or AT&T 6300 with a monochrome monitor:

    On some computers with built-in color capability but without color
    monitors, some text in the installation program may not be readable.
    Computers that might exhibit this problem include some laptops, IBM
    PS/2's, and AT&T 6300's.  Compaq's with "dual-mode" monitors do not
    seem to be affected.

    When you start the installation program, the message "Press Enter to
    continue" should appear on the bottom line.  If you can't read it, 
    press the Esc key (to exit), then "Y" and Enter (to confirm that you
    want to terminate the program.  Restart the installation program like
    this: 
            A:INSTALL -B&W
    Messages on the bottom line will now be readable.  (Network admin-
    istrators should note that this applies to the NUPDATE program as
    well.)

    If your screen is hard to read or if the View selection is not highlighted
    when you start Paradox, refer to the sections "If Your Screen is Hard to
    Read" and "Command Line Configuration" in Chapter 14 of the User's Guide.


Notes on the CONFIG.SYS file:

    Because Paradox 6.0 requires a hard disk, its installation procedure
    assumes that you boot from drive C: on your hard disk.  Therefore, it
    modifies C:\CONFIG.SYS (or writes it, if it does not already exist). 
    In a few cases, this is not the right thing to do, so you will have to
    vary the installation slightly.  These instructions may apply to you
    if:
  
        - you boot from a floppy disk
  
        - you boot from a hard disk drive or partition other than C:
  
        - you use OS/2.
  
    In all these cases, we have to depart from the standard Paradox 6.0
    installation to ensure that your machine is configured correctly when
    you start Paradox 6.0.
  
    The Paradox 6.0 installation sets FILES = 20 and BUFFERS = 20 in your
    CONFIG.SYS if it finds that they are currently set to lower values, or
    writes a CONFIG.SYS containing these two commands if you do not have
    one.  If you boot DOS from a drive other than C:, be sure that you have
    a CONFIG.SYS containing these two values on your boot disk.  You may
    copy the file that the Paradox 6.0 installation writes to C:, or create
    or edit CONFIG.SYS using a text editor.
  
    If you use OS/2, the situation is more complex, but not any more
    difficult.  Once again, it is only necessary to be sure that you start
    Paradox 6.0 with the correct configuration.  Follow whichever
    instructions here apply to you:
  
        - If your machine runs OS/2 but you want to boot DOS from a
    floppy disk and run Paradox 6.0, the notes above apply to you.
  
        - If your version of OS/2 allows you to boot DOS from the
    hard disk, the Paradox 6.0 installation will update CONFIG.SYS in the
    usual way, and DOS will read it at start-up.  You can run Paradox 6.0
    under DOS without making any changes.
  
        - If your version of OS/2 reads CONFIG.SYS when it boots up,
    you can run Paradox 6.0 in the DOS Compatibility Box without making any
    changes.  (You may delete the FILES command from CONFIG.SYS if you
    wish, since OS/2 ignores it.)
  
        - If your version of OS/2 reads CONFIG.OS2 when it boots up
    (as it will if it allows you to boot DOS from the hard disk), you may
    have to modify CONFIG.OS2 before you can run Paradox 6.0 in the DOS
    Compatibility Box.  If BUFFERS is set to a value less than 20, change
    it to BUFFERS = 20.  There is no need to add the FILES command, since
    OS/2 ignores it. 
  
  
Note for Torus Tapestry Users:

    The installation in the Network Administrators guide was written for
    Torus Tapestry II.  To install Paradox on Torus Tapestry II, run
    INSTALL and choose network installation from the main menu.  When asked
    what kind of network you are installing on, choose 7 - OTHER.  Do not
    choose 5 - Torus Tapestry; this menu choice should only be used if you
    are working with Torus Tapestry I.


2. Compatibility with Paradox 2.0
---------------------------------

    All Paradox 6.0 tables, forms and reports are 100% compatible with
    Paradox 2.0.  There are three minor revisions to Paradox menus which
    could affect script compatibility.  
    
    The IMAGE/GOTO menu has been changed to IMAGE/ZOOM.  
    
    The IMAGE/KEEPSETTINGS menu choice has been changed to IMAGE/KEEPSET.  
    
    If you choose TOOLS/COPY/FORM or TOOLS/COPY/REPORT you will now be
    taken to a submenu: SAMETABLE  DIFFERENTTABLE.  This menu change will
    allow you to copy individual forms and reports between different tables
    with the same structure.

    If your Paradox 2.0 scripts contain any of the above menu choices,
    changing them to the new menu choices will ensure compatibility with
    Paradox 6.0.
  
   
3. Form Design
--------------

Color Customization of Forms

    If you customize the colors of a form on a color monitor and then
    redesign the form on a monochrome monitor, you will lose the
    color attributes of the form.  Therefore, be very careful to change 
    color forms only on a color monitor.


Formatted calculated fields involving currency

    If the expression for a calculated field placed on a form contains a
    currency field ($), then the resulting calculated field will be
    formatted with commas, 2 digits after the decimal point, and
    parenthesis around negative numbers.


4. Multitable Forms
-------------------

Hiding fields on linked multitable forms

    If you are designing a linked multitable form, all fields which are in
    the key of the detail table must either be placed on the form of the
    detail table or used to link the table to the master table.  There are
    certain situations in which you will need to design a detail form which
    prevents users from accessing some or all of the key fields of the
    detail table, even though they must be placed on the detail form.  For
    example, if you are assigning values to the key fields through PAL, you
    would want to prevent users from accessing the key fields.  To prevent
    users from changing the data in the key fields, place them on the form
    as display-only fields.  
    
    If you also wish to prevent users from seeing the values in these key
    fields, use the STYLE/COLOR menu choice in form design to color
    the foreground and background identically for the fields you wish to
    hide.  This will render the fields "invisible".  If you are designing
    the form for use on a monochrome monitor you would still use
    STYLE/COLOR to make the foreground and background identical colors. 
    Paradox will then set the field display to monochrome attribute 0 (do
    not display).


Resynchronizing Records

    If the linking fields of a master table are changed, the master and
    detail records are resynchronized when you move to another record or
    when you move to another image in the form.  If you wish to
    resynchronize the records without moving to another record or another
    image, you may press the ReSyncKey [Ctrl][L].  Pressing this key will
    resynchronize the detail records for the new values in the linking
    fields of the master table. 

    Pressing this key will only resychronize records in edit or coedit
    mode, and only if the current image is the master table, not the detail
    table.  If you wish to use this key in a PAL application, it is
    activated by issuing the command: RESYNCKEY.


Working with Coedit in a multitable form

    UNDO: Once you leave the current master image of a multitable form, you
    cannot move back to that image and undo changes to that image.  For
    example, if you add a new detail record, once you move out of the
    current master image (back to table view, to another master record,
    etc.), you cannot undo your new detail record.
    
    POSTING RECORDS: If you are coediting the detail records of a
    multitable form and have not posted a record, leaving the detail table
    image will post the record.  That is, if you are in a detail record
    which has not been posted and you use UPIMAGE or DOWNIMAGE to move out
    of the detail image, the detail record will automatically be posted. 
    However, regardless of what image you are in, the master record of a
    multitable form will not be posted until you move to another master
    record or unlock the master record. 


5. DataEntry/KeepEntry and MultiEntry/KeepEntry
-----------------------------------------------

    If you finish a data entry or multientry session (MODIFY/DATAENTRY or
    MODIFY/MULTIENTRY) and you choose KEEPENTRY from the menu, the entry
    table will be displayed in table view, regardless of whether you
    performed your data entry in table view or in form view.  


6. Graphs
---------

    If you wish to graph the data from a table that is larger than 1,000
    records, use a query to consolidate or summarize the data before
    graphing it.  It should be noted that even graphing a table of 1,000
    records will produce a graph with so many points that you will not be
    able to distinguish one point on the graph from another.  It is best to
    graph data in much smaller tables.


7. Tools/More/Subtract
----------------------

    If you use Tools/More/Subtract with a source table that is keyed and a
    target table that is unkeyed, Paradox 6.0 will subtract all records
    from the target table that match the keys of the source table. 
    Documentation for Paradox 2.0 and Paradox 6.0 does not describe this
    case.


8. PAL
------

DEBUGTST script

    The PAL documentation describes a script called DEBUGTST.SC which you
    can use to learn the PAL debugger.  If you installed Paradox's sample
    tables, DEBUGTST.SC was copied to your hard disk along with them (usually
    to C:\PARADOX3\SAMPLE).  Otherwise, you can find it in the TABLES
    subdirectory of the Installation/Sample Tables Disk.
  
  
MOVETO

    If you are in a multitable form and you use the command MOVETO <image>
    or  MOVETO <number>, Paradox will only move to the specified table if
    that  table is in the multitable form.  If the table is not in the
    multitable form, you need to toggle to table view before you move to
    it. 
    
    If you are in the linked detail table of a multitable form, because
    record numbers in a detail area are numbered relative to the detail
    area (the first linked record is 1, the second is 2, etc.) MOVETO
    RECORD <number> will only move you to records that are linked to the
    current master record.
    

RESYNCKEY

    RESYNCKEY presses [Ctrl][L], the key which resynchronizes linked detail
    records in a multitable form.  For more information see the description
    in the Multitable Forms section of this file (section 3).


WAIT TABLE

    When in Edit, you can incrementally undo any changes you make to a
    table.  When you are working with a multitable form and you press Undo,
    Paradox will undo these changes incrementally, even if they span
    several tables.  To prevent your application from losing control, Undo
    has been disabled for multitable forms using the WAIT command.  To
    achieve the effect of Undo in your application, you can issue the
    command WAIT TABLE UNTIL "Undo" as demonstrated in the following
    segment of code:
    
        VIEW "customer"
        PICKFORM "F"                        ; a multitable form
        WHILE true
           WAIT TABLE UNTIL "F2", "Undo"
              SWITCH
                 CASE retval = "F2"
                    QUITLOOP
                 CASE retval = "Undo"
                    prevtable = table()     ; which table are we in before
                                            ; the undo?
                    UNDO
                    currtable = table()     ; which table are we now in? 
                                            ; at this point you could
                                            ; MOVETO prevtable
              ENDSWITCH                                          
        ENDWHILE                                    



9. Paradox Utilities
--------------------
    Your Paradox disks contain three utility programs that you may find 
    useful.  Because of their specialized nature, these utilities are not 
    automatically copied to your hard disk as part of the installation
    procedure.  All of them are stand-alone programs, so you run them from
    the DOS command prompt, not from inside Paradox.  They are:

FLIMPORT

    Paradox's Ascii/Delimited menu selection imports data from files in which
    trailing blanks are dropped from field values and values are separated 
    by commas (or another character of your choice).  Records in these
    files may vary in length.  Sometimes data is written in a fixed-length
    format instead.  In this case, trailing blanks are not omitted, so all
    values for a field are the same length, and separators are not needed
    to mark the end of each value.  Although Paradox cannot import these 
    fixed-length files, FLIMPORT.EXE (short for "Fixed-Length Import") can
    be used to import them directly into Paradox tables.  FLIMPORT is in the
    \UTIL directory on Personal Programmer Disk 6.  Refer to FLIMPORT.DOC,
    in the same directory, for more details.  (Some early copies of Paradox
    6.0 do not include FLIMPORT.  Any Paradox user who wants a copy of it
    should call Paradox Technical Support to request it.)


TUTILITY

    TUTILITY.EXE (short for "Table Utility") may be used to check if a Paradox 
    table is damaged; if it is, TUTILITY is usually able to reconstruct the
    table.  TUTILITY and it's accompanying documentation, TUTILITY.DOC, are 
    on the Installation/Sample Tables Disk.


VOUCH

    VOUCH.EXE is a simple checksum program.  If you contact Borland's Technical 
    Support Department for help using Paradox, and if there is any suspicion
    that your Paradox program files are not intact, the technician may ask
    you to run VOUCH.  VOUCH is on the Installation/Sample Tables Disk.



 
Data Entry Toolkit
------------------

ADDITIONS TO THE DATA ENTRY TOOLKIT

Record-level events:

    In addition to supporting keystroke, field, and table level events, the
    Data Entry Toolkit now also implements record arrival and record
    departure events.

    If you assign a record departure event for a table, DoWait will
    activate your procedure each time a user presses a key which will cause
    departure from the current record.  Note that DoWait will call your
    record departure procedures upon ANY attempt to leave a record,
    regardless of whether the attempt will be successful or not.  As with
    other kinds of event procedures, DoWait calls record depart procedures
    after a user presses a key which may cause movement out of the current
    record but BEFORE it passes the key to Paradox.  Thus if a user uses
    ZOOM (or ZOOMNEXT) to locate a value, DoWait will call your record
    departure procedures after the user presses Enter (or [Alt][Z]) to
    initiate the ZOOM but before Paradox executes the ZOOM.  DoWait status
    and control variables for field and table departure events are also
    available to your record departure procedures.

    DoWait calls record arrival procedures immediately after a user has
    entered a new record.  As in field and table arrival events, the DoWait
    control variable TKAccept has no effect since the user has already
    arrived in a new record. DoWait will invoke record arrival and
    departure procedures automatically when a user is moving between
    records.  Note, however, that if your procedures explicitly move a user
    to a new record, DoWait will not initiate record arrival and departure
    procedures.  You can call the ArriveRecord() procedure to have DoWait
    execute your arrival procedure or you can execute it yourself.

    You assign record-level event procedures through the SetUpDoWait
    subsystem of TKMenu.  To designate a record-level event procedure,
    simply place its name in the Procedure Name field next to the
    appropriate "Record Arrive" or "Record Depart" record of the TKTblLvl
    table.

    Note that DoWait is sensitive to changes in a table's structure and, in
    applications which use record-level events, the position of fields on a
    form. If you assign record-level procedures for a table, every time you
    change the position of fields on a form you MUST rerun SetUpDoWait.


    DoWait invokes events in the following order:

                |
                V
           Table Arrive <------------------------- Table Depart
                |                                       ^
                V                                       |
           Record Arrive                           Record Depart
                |                                       ^
                V                                       |
           Field Arrive <-------------------------------+ 
                |                                       |
                V
      Keystroke or Special Key <----- Bad Depart   Good Depart        
                |                          ^            ^
                V                          |            |
                +--------------------------+------------+


Demo.sc:

    Demo.sc allows you to run the DoWait demonstration from outside TKMenu.
    If you plan to step through the demonstration in debug mode, you'll
    need to play Demo since TKMenu is a password-protected script.


LookupSelect and LookupWait:

    You can now apply LookupSelect and LookupWait to all types of images,
    not only lookup help tables.  LookupSelect and LookupWait uses the
    ImageRights ReadOnly command to temporarily prevent a user from making
    changes to the current image.  If you have previously issued an
    ImageRights command on the image, you may need to re-issue the command.
    See LookSlct.sc and LookWait.sc for more information.


ReleaseWait:

    ReleaseWait, a new procedure, releases DoWait and its supplemental
    variables and procedures.  See ReleasW8.sc for more information.



CHANGES TO THE DOCUMENTATION:


Record-level Events:

    Because of the implementation of record-level events, all references to
    movement key procedures and TKMvmntProc are no longer applicable.

    In support of record-level events, DoWait now has an additional
    supplemental procedure: ArriveRecord.  ArriveRecord will invoke the
    record arrival procedure for the current table (if you've assigned
    one).


RecurseWait and TKDebug:

    The RecurseWait and TKDebug procedures, previously in Kernel.sc, are
    now in separate script files.  RecurseWait is now in RecursW8.sc. 
    TKDebug is now in TKDebug.sc.  Note that since DoWait now internally
    supports multiple table images, existing calls to RecurseWait may no
    longer be necessary.  Refer to the Data Entry Toolkit documentation for
    more information on removing your calls to RecurseWait.


Closed Toolkit Procedures:

    The table listing the various Toolkit utility procedures specifies
    several procedures which are "closed" procedures.  NONE of the Toolkit
    utility procedures are "closed" procedures.



SPECIAL NOTES:



Debugging Applications which Use Inactivity Procedures:

    If you incorporate inactivity procedures into your applications,
    pressing [Ctrl][Break] to step through a script will often leave you
    within the keyboard inactivity loop.  To instruct DoWait to continue
    pass the loop, assign the variable TKBuffer to the keycode of the next
    key you wish to process and [Ctrl][S] over the statement, "If
    Charwaiting()".


Using RecurseWait on Query Images:

    Should you desire to use DoWait on a query image, you'll need to use
    the RecurseWait variation of DoWait.  See RecursW8.sc for more
    information.


ArriveTable and ArriveRecord:

    When you explicitly move to another table within an event procedure,
    you must call ArriveTable or NewTable to alert DoWait that you have
    switched to another table image.  Note that ArriveTable and NewTable
    do NOT call ArriveRecord.  If you wish to invoke a record arrival
    procedure upon explicit movement to a new table, you must call
    ArriveRecord or your arrival procedure yourself.


Good Depart and Bad Depart Procedures:


    In the previous version of the Toolkit, putting an invalid value in a
    field within a Good Depart procedure would cause a script error, since
    Paradox does not allow movement out of an invalid field.  In this
    release, however, DoWait WILL activate the Bad Depart procedure for a
    field if your Good Depart procedure leaves invalid data in the field.


Interactions with Undo:

    When a user presses Undo within an Edit session (but not CoEdit),
    Paradox will sometimes move a user out of the current table and into
    another one.  This may occur, for example, when a user is editing a
    multi-table form.  DoWait has no way of knowing whether an Undo will
    take a user out of the current table until Paradox actually processes
    the Undo.  DoWait WILL activate table, record, and field arrival
    procedures for the new table, as well as the record departure procedure
    for the original table.  DoWait WILL NOT, however, call the table
    departure procedure for the original table.



Changing Forms of Tables with Record-Level Events:

    DoWait requires form specific information (generated by SetUpDoWait) to
    determine whether a key will cause movement out of a record.  Thus you
    MUST rerun SetUpDoWait every time you change the location of fields on
    a form of a table you use with DoWait.  Otherwise, DoWait will not
    properly activate your record-level procedures.
