Category: Constructing Expressions

Although every application has its own unique requirements, the individual components of applications are often very similar.

For example, menus, pop-up windows, and data entry forms and displays are common components of most applications. Pop-up windows, for instance, can vary in size, location and contents, but the commands to present them to the application user and to process the result of user interaction are essentially the same.

While Zim provides a great deal of flexibility in how applications can be designed and developed, experienced Zim programmers typically develop a programming style for various components of their applications. Consistency of style means that the application program code for one application object can be copied and modified when another, similar object is needed.

If a new pop-up window is needed, for example, the object definition and processing code for a similar, existing pop-up can be copied, and the necessary minor changes made. This approach can reduce development time considerably.

Template Definition

The template feature for Zim is a formal mechanism for producing reusable program code.

A template is an application program that contains the basic code for defining, presenting, and processing an application component such as a standard pop-up window. In addition, the template contains fragments of code that

• customize the basic code

• generate the application objects (e.g., windows, forms, variables) needed by the application components

Template Syntax

A template is similar to any other application program, in that it contains a series of command statements. However, a template is also different, in that it contains sections of code bounded by special template delimiters: << and >>.

The template delimiters are always placed at the start of a line; nothing else should appear on the same line. In this example,

… commands 1 …
<<
… commands 2 …
>>
… commands 3 …

the software handles the command statements that appear between the template delimiters differently depending on if the program is being executed, parsed, or compiled, or if it is being run under the GENERATE command.

During normal execution, commands 1 and commands 3 execute normally. Commands 2 are ignored.

With the PARSE or COMPILE command, commands 1 and commands 3 are parsed or compiles in the usual manner. Commands 2 are ignored.

With the GENERATE command, commands 1 and commands 3 execute normally. Commands 2 are sent as output, after macro substitution, to the current output device.

Program Call Syntax

The syntax of the call to the template program in the GENERATE command is identical to the structure of a call to a standard application program of the same type.

The rules for passing values to the parameters in a template program containing a formal procedure operate in exactly the same way as for an application program containing a formal procedure.

Program Execution

Program execution is handled slightly differently under GENERATE. Execution always proceeds interpretively, even if the template program has been compiled.

When the software encounters the << template delimiter alone on a line, execution is suspended, and the subsequent lines are written – after macro substitutions – to the current output destination. Execution resumes when the software encounters the >> template delimiter alone on a line.

Physical Line Handling

Normally, each physical line in the template is sent as a separate line to the current output destination.

To cause successive physical lines in the template to be joined into one line in the output, end the appropriate lines in the template with the dollar sign ($). At the output destination, the physical line containing the dollar sign and the next physical line appear concatenated on one physical line.

If a line must end with a dollar sign for another reason, direct the software to interpret the dollar sign literally by placing a backslash ( – Escape) preceding the dollar sign.

The result of an arithmetic expression contains as many decimal places as are found in the operands of the expression.

If the expression contains several operands with varying numbers of decimal places, the result takes on the number of decimal places found in the operand with the most decimal places.

If the result of the expression is assigned to an object with a numeric data type, the value takes on the number of decimal places defined for that object. If the object has fewer rounded decimal places than the expression’s result, the final value is rounded as shown in the following example:

Rounding occurs only after the entire expression has been evaluated. Therefore, in 1.01+(5/2), the fractional part of 5/2 is kept during the addition of 1.01. Because 1.01 has two decimal places, the result also has two decimal places.

Expressions can be combined in special ways to produce concise program statements that nevertheless have tremendous power and flexibility. The special expression formats are

• WHERE expression format

• assignment expression format

• grouped expression format

• case expression format

How To Use the WHERE Expression Format

A WHERE subcommand can be appended to a value expression to control the evaluation of that value expression. The syntax is

valexpression WHERE logic_expression

where valexpression is any value expression.

logic_expression is any logic expression.

If the expression is complex, it must be enclosed in parentheses.

If the WHERE condition evaluates to $True, the value expression is evaluated. If the WHERE condition evaluates to $False, the value expression is not evaluated, and the entire expression is considered to be $Null.

The WHERE expression format is frequently used with the case expression format, the assignment expression format, or with aggregate functions.

Examples of the WHERE Expression Format

(Salary – 20000) where Salary > 20000

(Salary – 20000) is evaluated only if the condition is met. The entire expression format takes on the value of the arithmetic expression if the condition is met; otherwise, it is considered to be $Null (valueless). The following example

let i = {  1 where Age < 10,      
    2 where Age between 10 and 30,  
    4 where Age > 50, 3}

assigns a value to a variable based on Age. The following example

compute Employees evaluate (let TotSal =     
  $total(Salary where LastName = “Smith”))

totals the salaries of all employees named Smith.

How To Use the Assignment Expression Format

A LET command can be used within an expression to assign a value to a target as the target is being used in a value or logic expression. The syntax is

(LET target=expression)

Where target is a global or local variable, a parameter, a field or a form field

where expression is any value expression.

Assignment expressions enable you to use fewer commands to achieve a particular result or to perform calculations within set-processing commands.

Examples of the Assignment Expression Format

while (let vCount=vCount-1)>0

Tests that vCount (which is first set to vCount – 1) is greater than 0.

let vTriple=(let vSingle=5)*3

Sets vSingle to 5 and vTriple to vSingle * 3.

(let vCount=vCount+1) where Processed=”yes”

Increments VCount if Processed is “yes”.

report footing (let TotalSal=$total(Salary)*1000)

Sets the variable TotalSal to 1000 times the running total of Salary, displaying TotalSal in the report footing. After the latter command has been executed (i.e., when the report is finished), the application retains access to the contents of TotalSal.

How To Use the Grouped Expression Format

Individual value expressions may be placed in parenthesis and separated from one another by commas to produce “grouped expressions”. The syntax is

(expression «,expr»)

where expression is any value expression. If the expression is complex, it must be enclosed in parentheses.

All the expressions are evaluated. The entire expression takes on the value of the last expression in the group.

Grouped expressions are useful for performing multiple assignments within one logic expression.

Example of the Grouped Expression Format

while ((let vTotal=0), (let vAverage=0), (let vCount=vCount-1)) > 0

let var1=((let var2=2), (let var3=3), 5-4)

How To Use the Case Expression Format

Case expressions provide a powerful method of dealing with evaluations that are conditional on the results obtained. The syntax is

{expression«, expr»}

where expression is any value expression, including another case expression.

The expressions within the braces are evaluated from left to right. The entire expression takes on the value of the first expression that is not $Null (valueless).

Each case within the braces is evaluated from left to right until one case yields a value that is not $Null. The case expression returns this value.

Case expressions can minimize the code that is required to produce certain conditional results as shown in the following example:

let Status = {“tall” where Height > 6, “short”}
replaces
if Height > 6
  let Status = “tall”
else
  let Status = “short”
endif

Case expressions can ensure that a value is provided in situations where a field or form field alone may sometimes be $Null, as shown in the following example:

let Salary = {fAddEmps.Salary, 0}

Case expressions can also be used to determine the action to be taken by certain commands, as shown in the following example:

break 1
  {$year(InvDate) + 1 where $month(InvDate) >= 5,
  $year(InvDate)}
  heading …

Examples of the Case Expression Format

let Status={“tall” where Height>6, “short”}

let ESalary={fAddEmps.Salary, 0}

detail line “Employee Number: ” {EmpNum, “N/A”}

See Also

$value

CASE

For Boolean Operators: AND, OR, XOR, NOT

For Conditional Operators: [NOT] BETWEEN, [NOT] IN, [NOT] LIKE, IS [NOT] $NULL

Truth Table for a Boolean AND Expression

expression1 AND expression2

If the conditional expressions linked by AND are

• both TRUE, then the Boolean expression is TRUE.

• both FALSE, then the Boolean expression is FALSE.

• one TRUE and one FALSE, then the Boolean expression is FALSE.

Truth Table for a Boolean OR Expression

expression1 OR expression2

If the conditional expressions linked by OR are

• both TRUE, then the Boolean expression is TRUE.

• both FALSE, then the Boolean expression is FALSE.

• one TRUE and one FALSE, then the Boolean expression is TRUE.

Truth Table for a Boolean X OR Expression

expression1 XOR expression2

If the conditional expressions linked by XOR are

• both TRUE, then the Boolean expression is FALSE.

• both FALSE, then the Boolean expression is FALSE.

• one TRUE and one FALSE, then the Boolean expression is TRUE.

Truth Table for a Boolean NOT Expression

NOT expression1

If the conditional expression preceded by NOT is

• TRUE, then the Boolean expression is FALSE.

• FALSE, then the Boolean expression is TRUE.

Truth Table for a [NOT] BETWEEN Expression

expression1 [NOT] BETWEEN expression2 AND expression3

A BETWEEN comparison is TRUE when

• expression1 is equal to or greater than expression2 and equal to or less than expression3

A NOT BETWEEN comparison is TRUE when

• expression1 is less than expression2

• expression1 is greater than expression3

The [NOT] BETWEEN comparison is FALSE in all other circumstances.

Truth Table for a [NOT] IN Expression

expression1 [NOT] IN (expression2 [«,expression3 »])

An IN comparison is TRUE when

• expression1 is equal to one or more of the expressions listed in parentheses

A NOT IN comparison is TRUE when

• expression1 is not equal to any of the expressions listed in parentheses

The [NOT] IN expression is FALSE in all other circumstances.

Note: Comparison ends as soon as a TRUE instance is found.

Truth Table for a [NOT] LIKE Expression

expression [NOT] LIKE pattern

A LIKE comparison is TRUE when

• expression matches pattern.

A NOT LIKE comparison is TRUE when

• expression does not match pattern

The [NOT] LIKE expression is FALSE in all other circumstances.

Truth Table for an IS [NOT] $NULL Expression

expression IS [NOT] [$]NULL

An IS $NULL comparison is TRUE when

• expression evaluates to $Null

An IS NOT $NULL comparison is TRUE when

• expression does not evaluate to $Null

The IS [NOT] $NULL expression is FALSE in all other circumstances.

An object that has not been assigned a value, or whose value is unknown, is considered to be $Null. For example, at the start of an application session, global variables do not have an assigned value, so each is considered $Null. If the name of an object with an unassigned or unknown value is used as an atomic expression, the expression is considered to be $Null.

The $Null property is special in two ways:

1. Any arithmetic or functional expression that contains a $Null value expression evaluates to $Null.

2. Any logic expression that contains a $Null value expression is considered logically false.

For example, if the variable Salary is $Null, then

Salary * 1.1 evaluates to $null, and Salary = 20000 is logically false.

However, you can successfully check if an expression is $Null. If Salary is $Null, then

Salary is $Null is logically true and Salary is not $Null is logically false.

Notice that conditional expressions involving the system variable $Null cannot use an = (equals) or <> (not equals) operator; instead, you must use the operator IS [NOT]. The use of IS and IS NOT emphasizes that $Null is a property and not a value.

Note: $Null can also be written Null.

A number literal is composed using the digits 0 to 9 and a decimal point (if desired). The number literal is automatically assigned the data type VASTINT, with a number of decimal places equal to the number of places shown in the expression.

The following numbers are examples of valid number literals:

5   234   0.5   468.55

The following groups of digits are not number literals

56,789   1 23

because the software does not enable commas or spaces to be used inside numbers.

Customizing applications for languages other than English

In Zim applications, some information that appears in the user interface, such as data masks, and error and processing messages, is language dependent. Zim provides tools to handle these dependencies and to make the application appear to the application user in languages other than English. A single application can be designed to handle several different languages simultaneously.

Language dependencies occur in four major areas of any application:

1. Character handling
   • definition of non-English characters
   • uppercase/lowercase translation
   • collating sequence for sorting, indexing, and comparing

2. Zim errors file
   • errors produced by Zim itself
3. Internal messages and strings
   • errors and processing messages produced for the application’s forms
   • day and month names
4. Data masking
   • numeric masks
   • alphanumeric masks
   • date masks

Tools used for adaptation

Zim provides three tools specifically geared to language adaptation:

• the developer-defined collating table
• the ability to translate error messages
• the ZIMLANG utility to alter masks, day names, and so on

The collating table is stored in the database. The collating table defines, internally to the system, how characters are represented and how they are to be sorted.

You can provide your own collating tables. For applications in languages other than English, the collating table enables you to properly handle special characters, such as accented characters.

Messages, strings, and mask characters can be customized for the desired language by translating the error message file or calling up the ZIMLANG utility.

Restrictions

Although Zim’s language-independence features solve a number of language adaptation problems, keep in mind these restrictions:

• Applications are developed in English
• You must ensure that output from an application is properly translated into the required language(s)

Numeric input/output can be adapted to another language only if it is controlled by a mask or numeric form field. Numeric values input from documents, including the terminal, or output without masks, appear in the original English format.

Zim does not recognize multi-character currency symbols.

Character Handling

Some languages use more characters than the twenty-six found in the English alphabet. These extra characters must be defined to ZIM in the collating table.

Collating Information

Zim uses a collating sequence that the database initialization program ZIMINIT reads from a collating table stored in an operating system file. The name of the collating file is operating system dependent. If the collating table is not found, Zim uses the standard collating sequence for your operating system.

Applications that have a requirement to define a collating sequence other than the standard ASCII collating sequence (i.e. programs that use accented characters) should rename the appropriate collating file in the Zim software directory to ” COLLATE.ZIM”. Renaming the file ensures that it is read by the Database Initialization program. In Zim for Windows, ZCOLLATE.DOS defines a collating sequence for all the OEM-accented characters while ZCOLLATE.WIN provides a collating sequence for the ANSI-accented characters.

The collating file is a text file that can be modified with any text editor that can handle ASCII characters. The file contains one entry per line. Each entry consists of the following information:

• character representation (the internal value that represents the character)
• collating value (the sorting value assigned by to the character by the developer)
• lowercase representation (the lower case equivalent of the character)
• uppercase representation (the upper case equivalent of the character)

Each field in an entry is separated from the next by a space. The characters can be entered as single characters that exist in your hardware’s character set or as a hexadecimal value. Hex values are entered in the format

hh

where hh is a pair of valid hex characters (0 to 9, a to f, A to F).

Entries in the collating table are governed by the following rules:

• A character is known as a letter if either its uppercase representation or lowercase representation differs from the value placed in the character representation field of the collating table.
• A character is upper case if it is a letter and if the character’s uppercase representation (the entry in the “uppercase representation” field) is the same as the character representation.
• Some characters, such as $, #, @ are the same regardless of case. Therefore the entry in either the “uppercase representation” field or the “lowercase representation” field is irrelevant.

Accented Characters

A developer can treat a series of similar characters in the same way. For example, the characters

• á
• â
• Ã
• a

can all be assigned the same collating value. For sorting purposes, à  and á would be treated the same way as a. This situation simplifies the data entry responsibilities of an application user. The user does not have to remember if a customer’s name, for example, contains an accent. On the other hand, record searches become more inefficient by having a wider scope (searches for records that contain a also return records that contain á and a).

The developer must decide if it is better for the application to differentiate between accented characters or to treat all similar characters in the same way. To differentiate accented characters, the developer can assign them collating values that correspond to user-defined locations in the normal collating sequence.

Zim error message translation

Error messages are produced from templates stored in the ZIM errors file. This file is described in Customizing Error Messages.

Error message prefixes ( eg *** Error***) and internally generated form messages can be modified using the ZIMLANG utility.

Using ZIMLANG

When customizing an application for a different language, internal strings (processing messages, day names, and so on) and mask characters must be taken into account. Strings and mask characters are customized through the ZIMLANG utility. For information on the use of the command, see ZIMLANG.

Internal strings

ZIMLANG can be used to modify the following types of strings:

• error message prefixes ( eg *** Error***)
• day and month names
• form error messages
• processing messages

When ZIMLANG is used to translate processing messages, formatting characters (such as / n, / r, / d) must not be changed, as they are the codes used to properly format the display of the messages.

Masks

Masks are used in reports and forms to precisely define how data is to be displayed. ZIMLANG can be used to replace the following mask characters with different characters:

• Date
• day (D)
• month ( M)
• year ( Y)
• numeric
• currency ($)
• comma (,)
• decimal point (.)
• alphanumeric
• various characters (?)

Several rules must be followed when translating mask characters with ZIMLANG:

• The mask characters for day, month, and year must be unique (i.e. the mask for day c
  annot be the same as the mask for month).
• The mask characters for the decimal point, the comma, and the currency symbol must be unique (i.e. the mask for the decimal point cannot be the same as the mask for the comma).
• ZIM developers can specify masks in a report, in the $mask function, and for a form field. Masks are always specified in English (the default format). ZIMLANG affects only how application users see masks in form fields and how they see masked values in form fields, reports, and the $mask function.

In reports and in the $mask function,

• only numeric masks are affected by ZIMLANG
• when a numeric mask indicates the presence of a decimal point, comma, or currency symbol, the newly defined character is used.
• application users never see the masks themselves, just the masked data.

In forms, all three classes of masks (date, numeric and alphanumeric) are altered by ZIMLANG, with the following results:

• In date masks, the new characters for day, month, and year replace the English characters
• In numeric masks, commas and decimal points in displayed values are replaced by the appropriate alternate language characters.
• In alphanumeric masks, mask characters (such as ?) are replaced with an appropriately defined alternate language character.

See Also

$mask

How To Use Data Masks

Arithmetic expressions use arithmetic operators to combine operands (typically value expressions). When evaluated, these arithmetic expression yield a numeric result, if possible.

Note: If the ^ character is unavailable, you can substitute **.

The standard rules of precedence for arithmetic evaluation are used.

Examples of arithmetic expressions follow:

Salary * 1.1

Salary + (Salary*0.1)

(! + InterestRate)^Years

The data types (CHAR, NUMERIC, INT, and so on) of the operands used in an arithmetic expression can be mixed. Operands that are character strings are translated (if possible) into an equivalent number, as shown below:

‘/’ evaluates to 0

‘-2’ + 5 evaluates to 3

‘2’ * ‘-4’ evaluates to -8

If a character string cannot be translated into a number (e.g., abcd), then an error message is returned, or the operand is treated as if it were zero.

Notes:

• Operators of equal precedence are evaluated from left to right in the expression.

• Parentheses can be used to explicitly determine the order of evaluation, overriding the order described above. Each pair of parentheses can contain only one arithmetic expression. Use parentheses extensively in arithmetic expressions.

An arithmetic expression is a complex value expression that consists of two or more value expressions and associated arithmetic operators.

The arithmetic operators are

• + (Add)
• – (Subtract)
• ^(Exponentiation)
• * (Multiply)
• / (Divide)

Examples of Arithmetic Expressions

For clarity, spaces can be used between operands and operators, but they are not required.

Salary * 1.1

or

Salary*1.1

Salary + (Salary * 0.1)

(1 + InterestRate)^Years

TotalPrice/Items

SellingPrice – (SellingPrice * BulkDiscount)

See Also

About Arithmetic Expressions

Arithmetic with Dates

Decimals and Rounding

Rules of Precedence for Operators