Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
INLIST()
This function determines whether the value of the first expression is in the list of values supplied. INLIST() works on almost every field type in Visual FoxPro—only General is excluded.
Usage
lIsItThere = INLIST( eExpression, eList1, eList2, ...)
|
Parameter |
Value |
Meaning |
|
eExpression |
Character, Memo, Currency, Date, DateTime, Double, Integer, Logical, Numeric |
The value to search for in the list. |
|
eListn |
Same as eExpression |
Valid values. |
|
lIsItThere |
.T. |
The matching item was found in the list. |
|
.F. |
The matching item was not found in the list. |
INLIST() does some conversion between related data types. If any one of the expressions is DateTime, dates are converted to DateTime by adding a time of “12:00:00 AM” (midnight). This can be a subtle gotcha—if your dates are converted to DateTimes by one rogue DateTime variable, the comparison must be exact, in date and time. Numeric, float, currency, integer and double values can be mixed with INLIST() without problem, as can character data and memo fields holding characters. Consistent with the rule that NULLs are propagated through functions, INLIST(.NULL., list,…) returns .NULL., and a .NULL. contained within the list results in a .NULL. return, if the value you’re trying to match is not in the list.
INLIST() is limited to 25 arguments in the list, or 26 parameters total. This is consistent with the limits of the MIN() and MAX() functions, but inconsistent with the UDF limit of 27 parameters. As we state below, if a list gets to this size, you probably should be using another method of storage besides hard-coding the list. INLIST() is case-sensitive, as shown in the third example below. There is no case-insensitive version as with AT() and ATC().
It is your authors’ feeling that while this is a nice function to use interactively, hard-coding acceptable values for a test may not always be the wisest path. Designing your system so additional cases may be added without changes to your program code can make your system easier to maintain and enhance. Storing the information you wish to compare in a table also opens up options of loading an array and using the ASCAN() function or performing the comparison with a Rushmore-optimized SEEK() or SQL SELECT WHERE…IN clause.
Example
? INLIST(27, 12, 27, 50) && returns .T.
? INLIST("one", "two", "three", "one") && returns .T.
? INLIST("one", "two", "three", "ONE") && returns .F.