C/AL is the application language used by Dynamics NAV and the Windows versions of Navision. From the character based version of Navision version 3.00's release in 1990 the langauge was called AL short for application language. When the Windows version of Navision was released in 1995 along with the other name changes AL became C/AL and the IDE became C/SIDE.
The application language in Dynamics NAV and Navision is based on the once very popular development language Pascal and it's basic structure and syntax is the same.
Almost every object in C/SIDE contains triggers where you can place your C/AL code. Triggers exist for the following objects:
You can initiate the execution of your C/AL code from the following:
Functions on any of the objects above
The following are simple guidelines for placing C/AL code:
The principle of placing code near the object on which it operates can be overruled in some situations. One reason to overrule this principle is security. Normal users do not have direct access to tables that contain sensitive data, such as the General Ledger Entry table. If you place the code that operates on the general ledger in a codeunit, give the codeunit access to the table, and give the user permission to execute the codeunit, you will not compromise the security of the table and the user will be able to access the table.
There are reasons other than security for putting a posting function in a codeunit. A function that is placed in a codeunit can be called from many places in the application, including, perhaps, some that you did not anticipate when you first designed the application.
The most important reason for placing C/AL code consistently, and as close to the objects that it manipulates, is that it lets you reuse code. Reusing code makes developing applications both faster and easier. More importantly, if you place your C/AL code as suggested, your applications will be less prone to errors. By centralizing the code, you will not inadvertently create inconsistencies by performing essentially the same calculation in many places, for example, in a number of control triggers that have the same table field as their source expression. If you have to change the code, you could easily either forget about some of these controls or make a mistake when editing one of them.
Curiosum:Just as Navision originally was Danish product, so was Turbu Pascal and Poly Pascal. These two once very popular Pascal products for DOS was developed by Danish programmer Anders Hejlsberg. Today he works for Microsoft as their lead architect on the C# language.
This info is awesome! Keep the good work goin' on Please!