Overview

Erik's ToolBox transforms Business Central into an interactive coding environment where you can write and execute AL code directly from your browser. Instead of following the traditional development cycle of writing code in Visual Studio Code, compiling an extension, publishing it, and installing it, you simply open the ToolBox editor, type your AL code, and press Run. Results appear instantly on the same page.

This chapter provides a high-level introduction to how interactive coding works in ToolBox, the underlying execution pipeline, and the scenarios where this approach is most effective.

The Concept: Interactive AL Scripting

At its core, the ToolBox interactive code feature is a REPL -- a Read-Eval-Print Loop -- built directly into Business Central. The REPL pattern is a well-established approach in software development where you:

Read -- Write or enter code into the editor.
Eval -- Execute the code immediately against the live Business Central environment.
Print -- View the results, console output, and any errors directly in the output pane.
Loop -- Refine your code and run it again, iterating as many times as you need.

This interactive style lets you experiment with AL code in real time. You do not need to create a project, configure a launch file, or deploy anything. You write code on the left side of the "Erik's ToolBox" page, press F9, and the output appears on the right.

The page caption reads "Erik's ToolBox - Interactive Code," and it is classified under Administration in Business Central's navigation.

How the Pipeline Works

When you press Run (F9) in the ToolBox editor, your code passes through a multi-stage pipeline before producing results. Understanding this pipeline helps you interpret error messages and write more effective scripts.

Stage 1: Source Code

Your AL code starts as plain text in the SourceEditor control. This is the raw input that you type or load from a saved program.

Stage 2: Lexer

The Lexer (codeunit Lexer) is the first processing stage. It scans your source code character by character and breaks it into tokens -- the smallest meaningful units of the language. For example, the text if Cust.FindSet() then is broken into tokens for the keyword if, the identifier Cust, the dot operator ., the identifier FindSet, the open parenthesis, the close parenthesis, and the keyword then.

The Lexer also handles:

Skipping whitespace and comments (trivia)
Tracking line numbers for error reporting
Identifying keywords, operators, literals, and identifiers
Filtering out bad tokens

Stage 3: Parser

The Parser (codeunit Parser) takes the stream of tokens from the Lexer and organizes them into an Abstract Syntax Tree (AST). The AST is a structured JSON representation of your program that captures the hierarchical relationships between statements, expressions, variables, and procedures.

For example, a repeat...until loop in your code becomes a JSON object with child nodes for the loop body and the condition expression. An assignment statement becomes a node linking the target variable, the := operator, and the value expression.

The Parser is where most compilation errors are detected. If you write syntactically invalid code -- such as a missing end; or an unexpected token -- the Parser reports the error with a line number and a description of what it found versus what it expected.

Stage 4: Compiler Validation

After parsing, the Compiler (codeunit Compiler) performs additional validation by calling the Interpreter's TestUnit procedure. This step checks for semantic issues that the Parser cannot catch on its own, such as duplicate variable declarations or unknown types. If any diagnostics are generated during this phase, they are merged with the Parser's diagnostics before execution is attempted.

Stage 5: Interpreter

If no compilation errors exist, the Interpreter (codeunit Interpreter) walks the AST and executes each node. The Interpreter directly interacts with Business Central's runtime to:

Read and write records in the database
Evaluate expressions and assignments
Call built-in functions like message(), error(), confirm(), and format()
Execute control flow statements (if/then/else, for, while, repeat/until, case)
Invoke record methods such as FindSet(), Insert(), Modify(), and Delete()

The Interpreter calls RunUnit() on the parsed AST to begin execution.

Stage 6: Results

Output from message() calls is captured by the console and displayed in the output pane. If errors occur during execution, they are reported as runtime diagnostics. The output pane shows both the console text and timing information (start time, end time, and elapsed duration).

The complete pipeline can be summarized as:

Source Code -> Lexer -> Parser -> AST (JSON) -> Interpreter -> Results

Console Output Capture

When you run a script in the ToolBox, the Interpreter captures all message() calls and redirects them to the console output pane rather than displaying them as standard Business Central message dialogs. This is controlled by the "Show output in console" toggle on the ToolBox page.

With console capture enabled, a script like:

var
    Cust : Record Customer;
begin
    if Cust.FindFirst() then
        message('First customer: %1', Cust.Name);
end;

displays the text First customer: [name] in the output pane instead of opening a modal dialog. This makes it practical to output many lines of information in a single execution without having to click through dialog boxes.

The console also includes timestamps. When execution starts, the console shows -- Started [datetime], and when it ends, it shows -- Ended [datetime] - Elapsed [duration]. This helps you measure the performance of your scripts.

Error Handling

The ToolBox reports two categories of errors: compilation errors and runtime errors.

Compilation Errors

Compilation errors are detected before your code executes. They are reported with a diagnostic type, a description, and a line number so you can locate the problem in your source code. The diagnostic types include:

Diagnostic Type	Description
Unexpected	The parser encountered a token it did not expect. The message tells you what it found and what it was expecting instead.
NotImplemented	Your code uses an AL language feature that the ToolBox compiler does not yet support.
DuplicateIdentifier	A variable or identifier has been declared more than once in the same scope.
IncompleteVariable	A variable declaration is incomplete or the variable was declared multiple times with conflicting definitions.
UnknownType	The declared type of a variable is not recognized by the compiler.
UnknownVariable	A variable is referenced in the code but was never declared.
UnknownOptionMember	An option value is referenced that does not exist for the specified option field.
Error	A general compilation error with a descriptive message.

Compilation error messages follow the format:

[Type] [Details] at line [LineNumber]

For example: Unexpected Got Semicolon, was expecting Identifier at line 5

Runtime Errors

Runtime errors occur during execution. These include standard Business Central errors such as record-not-found errors, permission errors, or division-by-zero errors. Runtime errors halt execution and display the error message in the output pane.

When the ToolBox Agent is active, the diagnostics of the last run are available to it: ask why the run failed and the agent reads them from the page and proposes a fix. See Coding Agent.

Comparison with Standard AL Development

The ToolBox interactive coding environment is designed to complement, not replace, traditional AL development in Visual Studio Code. The following table highlights the key differences:

Aspect	Visual Studio Code	Erik's ToolBox
Setup required	Install VS Code, AL Language extension, configure launch.json	None -- runs in the browser
Code execution	Compile, publish, install, then run	Write and press F9
Iteration speed	Minutes per compile-publish cycle	Seconds per execution
IntelliSense	Full VS Code IntelliSense with AL extension	Symbol-based IntelliSense for tables, fields, methods, and keywords
Output	Compiled .app file installed on environment	Instant on-screen console output
Persistence	Permanent extension deployed to environment	Scripts saved as programs or run on-the-fly
Debugging	Full VS Code debugger with breakpoints	Error messages with line numbers in output pane
Version control	Git integration in VS Code	Save/Load programs with optional Program Storage sync (Azure Blob Storage or GitHub)
Suitable for	Production extensions, large projects, team development	Ad-hoc tasks, data operations, quick diagnostics, prototyping

The ToolBox is ideal when you need results quickly and the overhead of a full development project is not justified.

Use Cases

Interactive coding in the ToolBox serves many practical purposes in day-to-day Business Central work:

Quick Data Fixes

When you need to update a handful of records, correct a misspelled field value across a table, or clear an erroneous posting flag, the ToolBox lets you write a targeted script and execute it immediately. There is no need to create a processing report or a codeunit in VS Code for a one-time fix.

Data Analysis

You can write scripts that iterate through records, calculate aggregates, and output summaries to the console. Combined with the Excel integration (using exget and exset functions), you can extract data from Business Central tables into a structured format for further analysis.

Automation Scripts

For recurring tasks, you can save your scripts as named programs and schedule them for automated execution through the Business Central Job Queue. This turns your interactive scripts into scheduled automation without any extension deployment.

Testing and Prototyping

Before committing logic to a production extension, you can prototype and test it in the ToolBox. This is especially useful for trying out record operations, validating business logic, and confirming that your approach works against real data.

Diagnostics and Troubleshooting

When investigating an issue in a Business Central environment, you can use the ToolBox to inspect data, check field values, verify record counts, and trace through logic interactively. This is faster than building a diagnostic codeunit or examining data through multiple pages.

Training and Learning

The REPL-style environment is an effective way to learn AL programming. You can experiment with language features, try different record operations, and see the results immediately without the complexity of managing a development project.

Getting Started

To begin writing interactive code in the ToolBox:

Open the Erik's ToolBox page in Business Central (search for "ToolBox" or navigate to it from the Administration area).
The editor appears on the left side of the page with a blank or default program loaded.
Write your AL code in the editor, starting with a var section for variables and a begin...end block for statements.
Press F9 or click the Run action to execute your code.
View the results in the output pane on the right side of the page.

For a detailed walkthrough of the editor features, continue to the next section.