Now we'll review the C/AL operators grouped by category. Depending on the data types we are using with a particular operator, we may need to know the type conversion rules defining the allowed combinations of operator and data types for an expression. The NAV Developer and IT Pro Help provides good information on type conversion rules. Search for the phrase Type Conversion.

Before we review the operators that can be categorized, let's discuss some operators that don't fit well in any of the categories. These include the following:

Following are the explanations regarding the uses of this set of symbols:

Arithmetic operators and functions

The Arithmetic operators include the following:

As we can see in the Data Types column, these operators can be used on various data types. Numeric includes Integer, Decimal, Boolean, and Character data types. Text and Code are both String data.

Following are sample statements using DIV and MOD, where BigNumber is an integer containing 200:

DIVIntegerValue := BigNumber DIV 60;

The contents of DIVIntegerValue after executing the preceding statement would be 3.

MODIntegerValue := BigNumber MOD 60;

The contents of MODIntegerValue after executing the preceding statement would be 20.

The syntax for these DIV and MOD statements is:

IntegerQuotient := IntegerDividend DIV IntegerDivisor;
IntegerModulus := IntegerDividend MOD IntegerDivisor;

Boolean operators

Boolean operators only operate on expressions that can be evaluated as Boolean. They are as follows:

The result of an expression based on a Boolean operator will also be Boolean.

Relational operators and functions

The Relational operators are listed in the next screenshot. Each of these is used in an expression of the format:

Expression RelationalOperator Expression

For example: (Variable1 + 97) > ((Variable2 * 14.5) / 57.332)

We will spend a little extra time on the IN operator, because this can be very handy and is not documented elsewhere. The term Valueset in the Evaluation column for IN refers to a list of defined values. It would be reasonable to define a Valueset as a container of a defined set of individual values, expressions, or other Valuesets. Some examples of IN as used in the standard NAV product code are as follows:

GLEntry."Posting Date" IN [0D,WORKDATE]

Description[I+2] IN ['0'..'9']

"Gen. Posting Type" IN ["Gen. Posting Type"::Purchase,
                        "Gen. Posting Type"::Sale]

SearchString IN ['','=><']

No[i] IN ['5'..'9']

"FA Posting Date" IN [01010001D..12312008D]

Here is another example of what IN used in an expression might look like:

TestString IN ['a'..'d','j','q','l'..'p'];

If the value of TestString were a or m, then this expression would evaluate to TRUE. If the value of TestString were z, then this expression would evaluate to FALSE. Note that the Data Type of the search value must be the same as the Data Type of the Valueset.

Precedence of operators

When expressions are evaluated by the C/AL compiler, the parsing routines use a predefined precedence hierarchy to determine what operators to evaluate first, what to evaluate second, and so forth. That precedence hierarchy is provided in the NAV Developer and IT Pro Help section C/AL Operators – Operator Hierarchy, but for convenience, the information is repeated here, in the following table:

For complex expressions, we should always freely use parentheses to make sure the expressions are evaluated the way we intend.

The MESSAGE function is easy to use for the display of transient data and can be placed almost anywhere in our C/AL code. All it requires of the user is acknowledgement that the message has been read. The disadvantage of messages is that they are not displayed until either the object completes its run or pauses for some other external action. Plus, if we inadvertently create a situation that generates hundreds or thousands of messages, there is no graceful way to terminate their display once they begin displaying.

It's common to use MESSAGE as the elementary trace tool. We can program the display of messages to occur only under particular circumstances and use them to view either the flow of processing (by outputting simple identifyng codes from different points in our logic) or to view the contents of particular data elements through multiple processing cycles.

MESSAGE has the following syntax: MESSAGE (String [, Value1] , ...]), where there are as many ValueX entries as there are %X substitution strings (up to ten).

Here is a sample debugging message:

MESSAGE('Loop %1, Item No. %2',LoopCounter,"Item No.");

The display would look similar to the following image (when the counter was 14 and the Item No. was BX0925):

When an ERROR function is invoked, the execution of the current process terminates, the message is immediately displayed, and the database returns to the status it had following the last (implicit or explicit) COMMIT function as though the process calling the ERROR function had not run at all.

An ERROR function call is formatted almost exactly like a MESSAGE call. ERROR has the syntax ERROR (String [, Value1] ,...]) where there are as many ValueX entries as there are %X substitution strings (up to ten). If the preceding MESSAGE was an ERROR function instead, the code line would be:

ERROR('Loop %1, Item No. %2',LoopCounter,"Item No.");

The display would look as shown in the following screenshot:

The big X in a bold red circle tells us that this is an ERROR message, but some users might not immediately realize that. We can increase the ease of ERROR message recognition by including the word ERROR in our message, as seen in the following screenshot:

Even in the best of circumstances, it is difficult for a system to communicate clearly with the users. Sometimes our tools, in their effort to be flexible, make it too easy for developers to take the easy way out and communicate poorly or not at all. For example, an ERROR statement of the form ERROR(' ' ) will terminate the run and roll back all data processing without even displaying any message at all. An important part of our job as developers is to ensure that our systems communicate clearly and completely.

The third dialog function is the CONFIRM function. A CONFIRM function call causes processing to stop until the user responds to the dialog. In CONFIRM, we would include a question in our text because the function provides Yes and No button options. The application logic can then be conditioned on the user's response.

CONFIRM has the following syntax:

BooleanValue :=  CONFIRM(String [, Default]  [, Value1]  ,...) 

When we do not specify a value for Default, the system will choose FALSE (which displays as No). We should almost always choose that option as a Default that will do no damage if accepted inadvertently by an inattentive user. The Default choice is FALSE, which is often the safest choice (but TRUE may be specified by the programmer). There are as many ValueX entries as there are %X substitution strings (up to ten).

If we just code OK := CONFIRM(String), the Default choice will be False. Note that True and False appear onscreen as the active language equivalent of Yes and No (a feature that is consistent throughout NAV for C/AL Boolean values displayed from NAV code but not for RDLC report controls displayed by the report viewer see NAV Developer and IT Pro Helps How to: Change the Printed Values of Boolean Variables).

A CONFIRM function call with similar content as the preceding examples might look as shown in the following for the code and the display:

Answer := CONFIRM('Loop %1, Item No. %2OK to continue?',TRUE,LoopCounter,"Item No.");

In typical usage, the CONFIRM function is part of, or is referred to, by a conditional statement that uses the Boolean value returned by the CONFIRM function.

An additional feature for on-screen dialogs is the use of the backslash () which forces a new line in the displayed message. This works throughout NAV screen display functions. Following are examples in Text Constants Text063 and Text064 in Table 36 – Sales Header:

To display a backslash on-screen, we must put two of them in our message text string, \.

The fourth dialog function is the STRMENU function. A STRMENU function call also causes processing to pause while the user responds to the dialog. The advantage of the STRMENU function is the ability to provide several choices, rather than just two (Yes or No). A common use is to provide an option menu in response to the user pressing a command button.

STRMENU has the following syntax:

IntegerValue := STRMENU(StringVariable of Options separated by commas 
[, OptionDefault][, Instruction])

Here IntegerValue will contain the user's selection and OptionDefault is an integer representing which option will be selected by default when the menu displays. If we do not provide an OptionDefault, the first option listed will be used as the default. Instruction is a text string which will display above the list of options. If the user responds Cancel or presses the Esc key, the value returned by the function is 0.

Use of the STRMENU function eliminates the need to use a Page object when asking the user to select from a limited set of options. The STRMENU can also be utilized from within a report or Codeunit when calling a Page would restrict processing choices.

If we phrase our instruction as a question rather than simply an explanation, then we can use STRMENU as a multiple choice inquiry to the user.

Here is an example of STRMENU with the instruction phrased as a question:

OptionNo := STRMENU('Blue,Plaid,Yellow,Hot Pink,Orange,Unknown',6,
                     'Which of these is not like the others?'),

Setting the default to 6 caused the sixth option (Unknown) to be the active selection when the menu is displayed.

Now we will review some of the functions that we commonly use in Record processing.

[BooleanValue :=] Record.SETCURRENTKEY(FieldName1,[FieldName2], ... )                 

Record.SETRANGE(FieldName [,From-Value] [,To-Value]);

Record.SETFILTER(FieldName, FilterExpression [Value],...);

[BooleanValue :=] Record.GET ( [KeyFieldValue1] [,KeyFieldValue2] ,...)

IF Customer.GET(NewCustNo) THEN ...

The FIND family of functions is the general purpose data retrieval function in C/AL. It is much more flexible than GET, therefore more widely used. GET has the advantage of being faster as it operates only on an unfiltered direct access via the Primary Key, looking for a single uniquely keyed entry. There are two forms of FIND in C/AL, one a remnant from a previous database structure and the other designed specifically to work efficiently with SQL Server. Both are supported and we will find both in the standard code.

The older version of the FIND function has the following syntax:

[BooleanValue :=] RecordName.FIND ( [Which] ).

The newer SQL Server specific members of the FIND family have slightly different syntax, as we shall see shortly.

Just as with the GET function, assigning the FIND function result to a Boolean value is optional. But in almost all the cases, FIND is embedded in a condition that controls subsequent processing appropriately. Either way, it is important to structure our code to handle the instance where FIND is not successful.

Following are several important ways in which FIND differs from GET:

Following are the various forms of FIND:

FIND ([Which]) options and the SQL Server alternates

Let's review the options of the FIND function using the following syntax:

[BooleanValue :=] RecordName.FIND ( [Which] )

The [Which] parameter allows the specification of which record is searched for relative to the defined key values. The defined key values are the set of values currently in the fields of the active key in the memory-resident record of table RecordName.

The following table lists the Which parameter options and prerequisites

The following table lists the FIND options that are specific to SQL Server:

For all FIND options, the results always respect applied filters.

The FIND('-') function is sometimes used as the first step of reading a set of data, such as reading all the sales invoices for a single customer. In such a case, the NEXT function is used to trigger all subsequent data reads after the sequence is initiated with a FIND('-'). Generally FINDSET should be used rather than FIND(' -' ), however FINDSET only works for reading forward, not in reverse. Or use FINDFIRST if only the first record in the specified range is of interest.

One form of the typical C/SIDE database read loop is as follows:

IF MyData.FIND('-') THEN
 REPEAT
 Processing logic here 
UNTIL MyData.NEXT = 0;

The same processing logic using the FINDSET function is as follows:

IF MyData.FINDSET THEN
 REPEAT
 Processing logic here 
UNTIL MyData.NEXT = 0;

We will discuss the REPEAT–UNTIL control structure in more detail in the next chapter. Essentially, it does what it says: "repeat the following logic until the defined condition is true". For the FIND–NEXT read loop, the NEXT function provides both the definition of how the read loop will advance through the table and when the loop is to exit.

When DataTable.NEXT = 0, it means there are no more records to be read. We have reached the end of the available data, based on the filters and other conditions that apply to our reading process.

The specific syntax of the NEXT function is DataTable.NEXT(Step). DataTable is the name of the table being read. Step defines the number of records NAV will move forward (or backward) per read. The default Step is 1, meaning NAV moves ahead one record at a time, reading every record. A Step of 0 works the same as a Step of 1. If the Step is set to 2, NAV will move ahead two records at a time and the process will only be presented with every other record.

Step can also be negative, in which case NAV moves backwards through the table. This would allow us to do a FIND('+') for the end of the table, then a NEXT(-1) to read backwards through the data. This is very useful if, for example, we need to read a table sorted ascending by date and want to access the most recent entries first.

In C/AL, there are instances where the syntax only allows for use of a single statement. But a design may require the execution of several (or many) code statements.

C/AL provides at least two ways to address this need. One method is to have the single statement call a function that contains multiple statements.

However, inline coding is often more efficient to run and to understand. So C/AL provides a syntax structure to define a Compound Statement or Block of code. A compound statement containing any number of statements can be used in place of a single code statement.

A compound statement is enclosed by the reserved words BEGIN and END. The compound statement structure looks like this:

BEGIN
  <Statement 1>;
  <Statement 2>;
  ..
  <Statement n>;
END

The C/AL code contained within a BEGIN – END block should be indented two characters, as shown in the preceding code, to make it obvious that it is a block of code.

IF is the basic conditional statement of most programming languages. It operates in C/AL similarly to how it works in other languages. The basic structure is: IF a conditional expression is true, THEN execute Statement-1 ELSE (if condition not true) execute Statement-2. The ELSE portion is optional. The syntax is:

IF <Condition> THEN <Statement-1> [ ELSE <Statement-2> ]

Note that the statements within the IF do not have terminating semicolons unless they are contained in a BEGIN – END framework. IF statements can be nested so that conditionals are dependent on the evaluation of other conditionals. Obviously, one needs to be careful with such constructs, because it is easy to end up with convoluted code structures that are difficult to debug and difficult for the developer following us to understand. In the next chapter, we will review the CASE statement which can make some complicated conditionals much easier to format and to understand.

As we work with the NAV C/AL code, we will see that often <Condition> is really an expression built around a standard C/AL function. This approach is frequently used when the standard syntax for the function is "Boolean value, function expression". Some examples are as follows: