Running an adapl

Normally, adapls are automatically run after some user action in a Collections application when you are already working in a database table, like when leaving a field or a screen, when opening or saving a record or after starting a print or export job.  However, it is also possible to run a stand-alone ADAPL program completely outside a Collections application. To start a compiled adapl from a (DOS) command-line window, you have to use either RunAdapl.exe (recommended from Collections 1.11, because it uses the base API and supports new database features like indexed links) or adeval.exe (which still works fine for old applications without the newer database features). RunAdapl.exe can be requested through our helpdesk while adeval.exe can be found and run from your Adlib \bin, \executables or \tools directory. Run a stand-alone adapl from the command-line as follows (and make sure the command prompt is already in the folder containing the executable because if you have to type a path in front of RunAdapl.exe it may no longer find any relative path to an .inf in a FACS declaration in the adapl, resulting in an error 55):

RunAdapl.exe adapl_name [arguments]

or

adeval adapl_name [arguments]

For the adapl name, fill in the name of an ADAPL executable (.bin) file. You can leave out the extension .bin. The arguments are an optional list of values that the adapl must use. The arguments must be separated by blank spaces. Arguments are only required if expected by the ADAPL program. Usually though, adapls do not require any arguments.

When an ADAPL program ends, it passes control back to the caller (i.e. the operating system or Collections). It may also pass back a code. For example, under DOS, adeval.exe will pass the exit code of the adapl back as 'error level', so that a script can use the result of the ADAPL procedure to determine what should happen next.

Eval

Both adeval.exe and the built-in version in Collections and adlwin.exe use eval: Eval is a function library for interpreting binary (compiled) ADAPL programs. Adeval.exe really is eval with a command-line interface, while in Collections and adlwin.exe it is hidden from the user. Eval itself was originally written as so-called unmanaged code in the C and C++ programming languages, just like adlwin.exe and wwwopac.exe. This old code in different Adlib software has largely been rewritten as managed code in the C# programming language, which allows for safer code and faster development, also resulting in RunAdapl.exe.
Managed code is safer than unmanaged code because in managed code array boundaries are checked, while in unmanaged code pointers are used. Also, managed code does not compile directly to machine code, but to intermediate code for which interpretation the Microsoft .NET Framework is required on the computer that is going to run the managed code.

More recent Axiell products are being written in C# completely, and to allow these products to execute adapls, eval has largely been rewritten in C# (although some rarely used reserved variables may still be missing) as well because the managed .NET environment cannot execute the unmanaged eval code.

The list below contains a list of reserved words (which cannot be used a variable names and such) in the C# version of eval and is complementary to the list of core ADAPL function names. The list comprises functions and instructions, internal variable or constant names, and words reserved for future use: and, do, else, end, gosub, goto, if, include, let, not, numeric, or, return, select, status, then, title, until, while.