Using C/AL

This section describes where to write C/AL code and how to reuse code.

For more information about using system-defined variables, see System-Defined Variables.

For more information about the most commonly used C/AL functions, see Essential C/AL Functions.

Where to Write C/AL Code

Almost every object in C/SIDE contains triggers where you can place your C/AL code. Triggers exist for the following objects:

  • Tables

  • Table fields

  • Forms, including request forms

  • Form controls

  • Reports

  • Data items

  • Sections

  • Pages

  • XMLports

  • Dataports

You can initiate the execution of your C/AL code from the following:

  • Command buttons

  • Menu items

  • Any object that has an instantiation of the object that contains C/AL code. An example of an instantiation is a variable declaration.


    If the C/AL code is in a local function, then you cannot run it from another object.

Guidelines for Placing C/AL Code

We recommend the following guidelines for placing C/AL code:

  • In general, place the code as close as possible to the object on which it will operate. This implies that code which modifies records in the database should normally be placed in the triggers of the table fields that are involved.

  • In reports, always maintain a clear distinction between logical and visual processing and position your C/AL code accordingly. This implies that it is acceptable to have C/AL code in a section trigger if that code controls either the visual appearance of the controls or whether the section should be printed. Never place code that manipulates data that is in the database in section triggers.

  • 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, nor do they have permission to modify objects. 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.

  • If you need user input for a function, such as a filter or sorting key, then we recommend that you use the RunObject Property of the menu item and then set a record as a parameter by reference on the codeunit that the RunObject property calls. For more information, see Programming Guidelines for Functions in Forms.

Reusing Code

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.

See Also


System-Defined Variables
Essential C/AL Functions