EVALUATION OPERATORS
SEMICOLON
COLON
APOSTROPHE
QUOTES
PARENTHESES
SQUARE BRACKETS
SPACES
CASE
OTHER OPERATORS ("<", "{", "%") - see STRING/EXPRESSION MANIPULATION OPERATORS
EQ, GT, LT, GE, LE, CO
Syntax:
Left side of test... EVALUATOR ...Right side of test
Description:
These are relational operators allowed only on "if" lines. You may use them to test how one value relates to another. They stand for what they appear to "spell." EQ means "equal to," GT means "greater than," LT means "less than," GE means "greater than or equal to," LE means "less than or equal to," and CO means "contains."
IMPORTANT: Remember that the evaluation operators (EQ, NE, GT, GE, LT, LE, CO), are ALWAYS tests and may only be used on "if" lines. For example:
If: 3 eq "14"
will work properly, and:
Then: 3 eq "14"
has no meaning, and will generate a syntax error.
IMPORTANT: Numeric Compare vs. ASCII Compare
All of these evaluation operators perform the proper tests based on the type of data used in the evaluation. In other words, if you are testing one numeric field against another numeric field, the evaluation will be numerical. If you are testing ASCII values (non-numeric data), the comparison will be an ASCII comparison. This is an important concept to understand when performing tests.
@keyT If:
Then: aa(2)="bb"
If: aa gt "13"
Then: show "@Yes, bb is greater than 13" ; end
The test shown above will prove true, and this may not be what you would expect. If the dummy variable aa is filled with the literal string "bb", this test will prove TRUE. This is because the ASCII value of "bb" is higher than the ASCII value of "13". Just be careful to compare numbers against numbers if that is what you need to do.
Numeric compares (numeric data) will work the way you would expect. "3" will be less than "749". ASCII compares may not work the way you might expect, that is, until you get used to the ASCII sorting order employed by all data base applications.
To further explain this difficult concept, examine the following:
@keyT If:
Then: aa(2)="S"
If: aa gt "Broadway"
Then: show "@Yes, it is" ; end
This will test TRUE, simply because "S" is higher in ASCII value than "B", the first letter in Broadway. The "S" comes after (or higher than) "Broadway" in an ASCII sort. In the same way, the string "1111" would come before "2" in an ASCII sort (or be less than 2 in an ASCII compare). Think of the alphabet or the numbers, not the length, when you are thinking about an ASCII compare or an ASCII sort.
The EQ Operator
IMPORTANT: Evaluation vs. Assignment
The EQ operator is special in one regard. The equal sign maybe substituted for this operator. It is STRONGLY recommended that you do not use this convenience, as it will make your processing tables harder to read. If you do use the equal sign "=" in place of the EQ operator, you will be using the equal sign to perform double duty on your processing tables. Be aware of the significant difference between the two functions evaluation and assignmnet.
= Evaulates to the same value in a compare. (Only on "if" lines.)
or
= Assigns the value on the right side to the field on the left side.
In other words:
Then: aa="Hello"
the above code sets the value of field aa equal to "Hello", and:
If: 3 = "C"
tests for equality between the contents of field 3 and "C". Again, it is STRONGLY suggested that you do NOT ever do this. Instead, always use only the EQ operator to test for equality, as in:
If: 3 eq "C"
This will make your code much easier to read, since the EQ operator and other relational tests are NOT ever allowed on "then" lines, and you will know that every "=" means assignment.
The CO Operator
NOTE: The CO operator is very powerful and can be used in many different ways.
If: "TheForNotIfAnd" co 3
Then: show "@Yes, it does" ; end
If field 3 exactly contains any of the little words (The, For, Not, If, And), the test will prove TRUE. Of course, if field 3 is equal to "hef" or "rNo" or "fan", it will also prove true. Be careful when doing such "backward" compares.
IMPORTANT: All the evaluation operators do not take case into account. Therefore, "good", "Good", "gOOd", etc., are all the same for purposes of the compare.
S
; U Description:
Separates statements.
Examples:
Then: aa=min(2);screen "4" ; end
Use good judgment when separating statements on a line. If it makes more sense to put the statements on separate lines, there is no problem with doing this.
Then: a=4 ; aa=44 ; bb="fred" ; cc="temp" ; display ; RETURN
might be written as:
Then: a=4 ; aa=44 ; bb="fred" ; cc="temp" ; display
Then: RETURN
This places the RETURN command on a line by itself, and using upper case makes it stand out even more. Any tricks like this you can use to make your code easier to understand are usually desirable. As with everything else in programming, consistency is more important than the style content.
: COLON
Description:
Performs alias assignment. In other words, substitutes one way of referring to an item for another way of referring to that item.
Examples:
Then: BALANCE:14
The above sets the alias name BALANCE equal to field 14. BALANCE may then be used interchangeably with field 14 elsewhere on the table.
Then: dim TOTALS[10]:14
The above sets (or aliases) a 10 element array called TOTALS to overlay the file starting at field 14. The first element in the array would be equal to field 14, the second would be equal to field 15, etc., up to the 10th element.
' APOSTROPHE
Description:
An apostrophe placed anywhere on an "if" or "then" line, makes the rest of the line a comment or remark. These comments are ignored by filePro.
Restrictions:
You can NOT use a comment in a "label" field.
Examples:
If: tot(2) gt "4" 'is total of field 2 greater than "4".
It is STRONGLY suggested that you use comments liberally. Try to explain in words what the processing is going to accomplish. This will help you a great deal when reading old code, and it's invaluable to others who might have to read your code.
It is allowable to have only comments in a processing element.
If: 'The following lines get a free record from invoice file
Then: 'and post the customer code and new inv# to the new record
Then: lookup invoice r=free -e
Then: invoice(1)=CUSTCODE ; invoice(2)=nn
Comments are what separate great programmers from good ones.
" " QUOTATION MARKS
Description:
Indicate a literal. Literals are any string of characters, that are not an expression for something else. They are ment to be used exactly as they appear between the quotes.
Examples:
Then: ab="Hello"
Then: xx=asc("J")
It is VERY IMPORTANT that you DON'T use quotes around a filePro field, either real fields or dummy fields. It is equally IMPORTANT that you DO use quotes around numbers which are meant to be literal values.
Correct:
Then: 4="96" 'sets field 4 equal to the value "96"
Unusual (but acceptable):
Then: 4=96 'sets field 4 equal to the value found in field 96
It may be that you WANT to do the "Unusual" statement shown above for some reason. This is fine, as long as you are SURE you know the difference between these two very different lines of code.
Completely wrong:
Then: "4"=96 'this can never be done, it's illegal
( ) PARENTHESES
Description:
Parentheses perform several different functions.
a) Parentheses change operator precedence (as in algebra).
Then: aa=(ab + "1")/2
Expressions inside parentheses are resolved first. The above example would yield a much different result if written as:
Then: aa=ab + "1"/2
This is because multiplication and division are performed before additions and subtractions.
b) Parentheses hold arguments.
Then: aa=avg(14)
The value in field 14 on each record encountered is passed to the AVG function.
c) Parentheses hold variable filenames, screen names, and fields.
If: 3="V"
Then: ff="vendors"
If: 3="C"
Then: ff="customers"
Then: lookup (ff) r=free -ep
or
Then: ff="/tmp/file.asc"
Then: export ASCII (ff) -X
or
Then: screen (ff),(gg) 'puts cursor on screen "test" in field "2"
[ ] SQUARE BRACKETS
Description:
Square brackets have only one use on filePro processing tables. They may be used with the DIM command instead of parentheses. It is STRONGLY recommended that you do this to make your code easier to read. Every time you refer to arrays during their creation or use, employ square brackets.
Examples:
Then: dim inv[10]
Then: inv[3] = 14
The above are better than:
Then: dim inv(10)
Then: inv(3) = 14
this is because, it would be immediately obvious that inv[3] refers to an array rather than a lookup field. (NOTE: While it is true that the subscript of an array is "usually" in quotes, the above code is legal. Using a real field as a subscript of an array is valuable only in limited circumstances, and truly it is only then that an array element might look like a lookup field, but using square brackets for arrays nonetheless keeps them clearly set apart from lookup in general.)
SPACES SPACES ON PROCESSING TABLES
Description:
SPACES have limited significance on processing tables. Unless they are a part of a literal (within quotes or a quoted string), or part of a command and its arguments, SPACES do not change the way a filePro processing table will compile.
Examples:
Then: aa=24+"1"
Then: aa = 24+"1"
Then: aa= 24 + "1"
The above are all identical and legal.
Then: aa= 2 4 + "1"
The above is not legal, and will yield an syntax error.
Of course, any processing table command or function, and any filename or alias must be followed by a space.
You can not use:
Then: lookupfilenamek=1i=a
but you could use:
Then: lookup filename k=1i=a
However, it is STRONGLY suggested that you do not use SPACES improperly. For example, one small change in the above code makes it not work.
Then: lookup filename k=ii=a
The above will not pass a syntax check. Even though there might be an index.I (capital I) and even though filePro normally ignores case, it will get confused by the above.
If you are unsure, it is usually best to use a SPACE when you are in doubt.
FilePro will not compile a faster table if you try to remove all the unnecessary spaces. Use them liberally to make your code easier to read.
If: 23co oc
The above example will work, but it would be much better written as:
If: 23 co oc 'does field 23 contain the value in dummy OC?
and
Then: 16=3*mid(1,"1","2")+aa/"-1"
might be easier to read as:
Then: 16 = 3*mid(1,"1","2") + aa/"-1"
Whichever way you decide to use SPACES on processing tables, the very best thing you can do is be consistent. If you put a SPACE before and after each semicolon, do it all the time.
Then: 4=b;aa="Ma" ; gosub xxx; k="" ; show "@hello"; end
The above example would be much easier to read as:
Then: 4=b ; aa="Ma" ; gosub xxx ; k="" ; show "@hello" ; end
or
Then: 4=b;aa="Ma";gosub xxx;k="";show "@hello";end
or
Then: 4=b; aa="Ma"; gosub xxx; k=""; show "@hello"; end
Since SPACES can be used in such a variety of ways, it is simply a matter of good style to pick a convention and use it all the time. Your coding will be easier to read and debug if you use SPACES in a consistent manner.
NOTE: If you redirect processing with the GOTO command, anything following that command (even if separated by a semicolon) will NEVER be executed. The GOTO command is always the last executed command of any line.
Also, the file-handling functions LOOKUP and EXPORT can not have anything following them on the line.
IMPORTANT: When you use @wlf and @wef processing, there is a small set of commands, one of which MUST be used to close-off or end the @when processing. These commands are END, SCREEN, ESCAPE, RESTART and SKIP. @when processing MUST have one of these commands to end its work. Placing a semicolon and any commands after one of these closure commands while inside @when processing will result in these commands NEVER being executed. This is without doubt the major cause for improperly working tables among beginners and experts alike.
@wlf2 If:
Then: 5="OPEN" ; screen 2,7 ; gosub totals ; display ; end
The GOSUB, DISPLAY, and END commands will never be executed because the SCREEN command is one of the special ones that ends an @when routine.
Conversely, and equally IMPORTANT, the following code demonstrates a major source of problems:
@wlf2 If:
Then: 5="OPEN" ; popup update -,3
@wlf5 If: 5="CLOSED"
Then: aa=aa+"1" ; display ; end
Many filePro programmers first assume that since they have put the user onto SCREEN 3 with this code, the next time the user saves the record, the INPUT processing table will start at the top. It will not! It will start running right where it left off immediately after the POPUP UPDATE command. This is because the @when processing @wlf2 has not been properly closed with one of the special closure commands listed above. The code as shown here will incorrectly "fall through" to the @wlf5 processing that you do not want to run unless the user is actually leaving field 5.
CASE UPPER AND LOWER CASE
Description:
Upper and lower case letters are interchangeable on filePro processing tables. They have no special meaning except in literals, and filenames under Unix.
Examples:
Then: AA=aa+"1"
Then: Aa=aA+"1"
Then: aa=aa+"1"
The above are all identical and legal.
If: 3 eq "Mary"
If: 3 eq "mary"
The above are identical and test the same. This is because filePro ignores case when doing comparisons. (Unless you use the COMPARE function.)
However,
Then: show "Hello"
Then: show "HELLO"
will show exactly what is contained inside the quotes, respecting the case. This is how "literals" work. They mean "literally" what is contained within the quotes.