By popular demand _some_ instructions  for getting the most of
FE Asist. It does not cover every function (yet), FEASIST.TXT is the
complete reference of each function and its usage.



===========================[SUPERBROWSES]=====================================

First of all, what is this.  When you press the browse button,
using this feature will give you incremental searches "tippy type",
on all fields that have indexes.  My clients find this feature much
better than using the find dialog.

In order to activate this feature you must type:

*[BROWSE:<fieldlist>:]

In the notes section of the table (not the fields) of the data dictionary.
<fieldlist> is a comma delimited list of fields (all caps) without
the DBF before them.  As in:

*[BROWSE:NAME,SALARY,PHONE:]

Not:

*[BROWSE:empl.name,empl.salary:]

You must _not_ have designed one of FE's custom browses for the screen.
Neon has left no data dictionary hooks for this and actually places
code for the custom browse in your screen.  If you already have done this,
comment out the __m.browseproc="xxxxBROWSE"__ line in the SETUP snippet
of the screen.

The first time you hit the browse button FEASSIST calculates the SIZE
and browse expression for your browse and stores them in the Notes field,
(actually EXPRESSD.DEVNOTES) so that the next time you hit the browse key
it doesn't need to perform those calculations (that means performance!).

Soooo, if you change the *[BROWSE:<fieldlist>:] you must _DELETE_ the
*[SIZE:<size>:] and *[BROWEXPR:<browse expression>:] lines so that they will
be recalculate.  If you are ambitios and understand BROWSE, you can directly
manipulate these instructions.  The BROWEXPR instruction looks something
like:

*[BROWEXP:DESCR:W=JTAG('DESCR'),CUSTNO:W=JTAG('CUSTNO'):]

Which you could further manipulate to change headings, widths, etc.

If you want your incremental search to be case sensitive place the
instruction:

*[MIXEDCASE:YES:]
in the Notes field.




==========================[Ultra PickLists]===================================

If your tables get large, then using the FE arraybased pick list becomes
slow.  Using a JKEY pick list will use a browse instead of an array based
list giving lightening performance.  You also have the added benefit of
being able to have custom headings an the ability to have incremental
searches on all the fields in your pick list (they must each have an index).

To FEASSIST for this type of pick list, set up your FoxExpress lookup
in the normal fassion.  In the PopUp expression list the fields without
DBF.FIELD separated by "+" with no spaces as in:

LASTNAME+FIRSTNAME+PHONE

You must type the instruction:

*[JKEY:YES:] or *[JKEY:MIXEDCASE:]

in the Notes (EXPRESSD.DEVNOTES) section of the field. MIXEDCASE is used
to enabel case sensitive searches.

As in the SUPER BROWSE, the first time you run Ultra Picklist, calculations
are performed and *[SIZE:<size>] and *[BROWLST:<expr>:] are stored in
the Notes field.  You can manipulate these in the same manner as in
SUPER BROWSE



========================[Filtered Pick Lists]=================================

There are many situations in which you want to set a filter on a pick list.
For example, you may have a pick list on jobs, then you want a pick list
on phases just for the job you have already chosen. To use this feature,
which works on Ultra Pick lists and normal ones place the *[LIMIT:<expr>:]
instruction in the notes field.  The following example limits locations
to the current customer:

*[LIMIT:"ARLOCN.CUSTNO='"+M.CUSTNO+"'":]

Notice the quotes, your expression will be placed in a variable (lcFilter)
and evalueated via &lcFilter.



[Pick List Titles]

To create a custom title for you pick list place the instruction
*[PICKTITLE:<title>:] in the notes field.  As in:

*[PICKTITLE:Customer List:]

Notice that no quotes are needed.



============[List of Open Screens under the Window menu]======================

WINDLIST enables you to place the name of all open screens under the Window
menu pad and by selecting the menu uption bring forward the screen.  In my
applications each data entry screen takes up the whole screen, thus other
open screens are inaccessable.  Now my users simply bring up a list of the
open screens and choose the one the want to bring forward.  After all, what
use is there in having the ability to open a bunch of screens if you can't
easily switch between them.

To use this feature place the following in the SETUP SNIPPET of each data
entry screen (only the first one in a set):

DO WINDLIST WITH "<screen name>","ADD"

Where <screen name> is the name of the window as displayed in the screen
options for the screen (FE defaults each screen name to the name of the
primary database).

Place the following in the CLEANUP SNIPPET of each data entry screen (only
the first in a set):

DO WINDLIST WITH "<screen name>","REMOVE",m.action

Where <screen name> is the same as in the SETUP SNIPPET.

You must have a Menu Pad named "Window" (which is in the FE default menus)
for this to work.



=========================[ Table Linker ]=====================================

One of the hassles in using the Screen builder is including fields from
related table.  Simply setting relationships between files and placing
fields from the related talbes on the screen does not work when using
memory variables as FoxExpress does.  Neons' solution is calling the
function SETPOINT from the SHOW snippet.  Neons' routine is slow and gets
more slow as the number of related tables increases.  LEEPOINT is an
optimized replacement for SETPOINT.

This function allows you to place fields from related tables on your
screens. This function is called from the SHOW snippet.

=LEEPOINT(@LAJOINS)

The array laJoins should be created in your SETUP snippet:

DIMENSION laJoins(1)
=JOINARAY(@laJoins)

Also:

1. You must open all tables in your SETUP snippets that appear on your
   screen.

2. Do not set relations between the files.

3. Place the line:
     =LEEPOINT(@LAJOINS,.T.)
   immediately after:
     CASE m.action="ADD"
   in your control panel.  This will set the related tables to EOF() at
   the beginning of your add routine.  Otherwise, your users will see
   false values at the beginning of adding new records.

4. If you have complex relationships include a second parameter in your
   JOINARAY call:  =JOINARAY(@laJoins,.T.) which will remove cyclical
   relationships, but will take longer to process.


=========================[ Mega Delete ]=====================================

Neon's DDDELETE program only looks two levels deep to determine if a record as
dependant relationships.  LHDELETE handles relationships of any complexity and
will cascade delete any number of levels.  Also LHDELETE presents the user
with thermometers detailing the progress of a deletion - really important for
those highly "connected" files.

Simply place the line RETURN LHDELETE() as the first line in DDDELETE.
