Improve your AL standard with StandardDialog

In the last few weeks, I have found myself using the Standard Dialog page type way more. In this video I show how I’m using the Standard Dialog in Microsoft Dynamics 365 Business Central AL.

https://youtu.be/ITVF1w5oYxg

In this video, Erik demonstrates how to use the StandardDialog page type in Business Central AL development. He walks through creating a standard dialog page from scratch, explains what makes it different from other page types, and shows a clean pattern for passing data in and out of the dialog using page variables with setup and getter functions.

What is a StandardDialog?

If you’ve worked with Business Central, you’re familiar with list pages, card pages, and fact boxes — the standard building blocks of the UI. But there’s another page type that often goes underused: StandardDialog.

A standard dialog is a reduced page type that presents the user with a simple form along with OK and Cancel buttons. You can see an example of this in the base application — if you open the User List, go into a user card, and click “Change Web Service Key,” the page that appears is a standard dialog.

The key difference from a regular card page is that the OK/Cancel paradigm gives you a clear commit-or-abort workflow. Nothing has to be written to the database until the user explicitly clicks OK. This makes it ideal for gathering user input before performing an action.

Creating a StandardDialog Page

Let’s start by creating a simple standard dialog page. The critical property is PageType = StandardDialog:

page 51100 "Standard dialog test"
{
    PageType = StandardDialog;
    Caption = 'This is the caption';
    layout
    {
        area(Content)
        {
            field(x; x)
            {
                ApplicationArea = all;
                Caption = 'This is X';
            }
            field(y; y)
            {
                ApplicationArea = all;
                Caption = 'This is Y';
            }
            field(z; z)
            {
                ApplicationArea = all;
                Caption = 'This is Z';
            }
        }
    }
    procedure Setup(_x: Text; _y: Text; _z: Text)
    begin
        x := _x;
        y := _y;
        z := _z;
    end;

    procedure GetX(): Text
    begin
        exit(x);
    end;

    procedure GetY(): Text
    begin
        exit(y);
    end;

    procedure GetZ(): Text
    begin
        exit(z);
    end;

    var
        x: Text;
        y: Text;
        z: Text;
}

What Works and What Doesn’t

The StandardDialog page type is deliberately reduced in functionality. There are some important limitations to be aware of:

  • Actions are ignored — If you add actions to the action bar, they simply won’t appear. The only interaction points are the OK and Cancel buttons.
  • FactBoxes are ignored — You can define a FactBoxes area in the code without getting a compile error, but nothing will render. Microsoft doesn’t validate this at compile time, but the area simply has no effect.
  • Content area is the only usable area — All your fields, labels, and groups must go in the area(Content) section.

Calling the StandardDialog with the Page Variable Pattern

The real power of the standard dialog comes from how you call it. Rather than using Page.RunModal as a static call, Erik recommends declaring a page variable. This is key because the page variable’s lifetime extends beyond just the page being open — it lives from the moment it’s declared until it goes out of scope.

This means you can:

  1. Call a Setup procedure to pass data into the page before it opens
  2. Run the page modally and check whether the user clicked OK or Cancel
  3. Call getter procedures to retrieve data out of the page after it closes

Here’s the page extension that demonstrates this pattern on the Customer List:

pageextension 51100 "Standard dialog ext" extends "Customer List"
{
    actions
    {
        addfirst(processing)
        {
            action(Test)
            {
                Caption = 'Test Standard Dialog';
                ApplicationArea = all;
                Promoted = true;
                PromotedCategory = Process;
                PromotedIsBig = true;
                PromotedOnly = true;
                trigger OnAction()
                var
                    SD: Page "Standard dialog test";
                begin
                    SD.Setup('Erik', 'Soccer', 'Euro 2020 in 2021');
                    if SD.RunModal() = Action::OK then begin
                        message('%1 %2 %3', SD.GetX(), SD.GetY(), SD.GetZ());
                        message('%1 %2 %3', SD.GetX(), SD.GetY(), SD.GetZ());
                    end;
                end;
            }
        }
    }
}

How the Pattern Works Step by Step

  1. Declare the page variable: SD: Page "Standard dialog test";
  2. Call Setup before opening: SD.Setup('Erik', 'Soccer', 'Euro 2020 in 2021'); — This populates the fields so the dialog opens with pre-filled values.
  3. Run the dialog and check the result: if SD.RunModal() = Action::OK then — If the user clicks OK, proceed; if they click Cancel, do nothing.
  4. Retrieve the values: SD.GetX(), SD.GetY(), SD.GetZ() — Even though the page is now closed, the page variable is still in scope, so you can read the values the user entered.

When running this, the dialog opens with the fields pre-populated. The user can modify the values, and if they click OK, the calling code retrieves whatever the user entered. If they click Cancel, the code skips past the if block entirely.

Important Limitation: You Can Only Open It Once

There is one notable limitation with page variables: you can only call RunModal once per page variable instance. If you try to call SD.RunModal() a second time, you’ll get an error saying “the object has been run.”

If you need to open the dialog again, you would need to call Clear(SD) first — but be aware that this resets the entire internal structure of the page variable, including any values set via Setup.

However, calling the getter functions multiple times after the page has closed works perfectly fine. As demonstrated in the code above, SD.GetX() can be called as many times as needed — there’s no “read once” restriction on retrieving data.

Why Use StandardDialog Instead of Other Approaches?

In the older days of NAV/Business Central development, developers often misused report request pages to gather user input before performing an action. The standard dialog approach is much cleaner for several reasons:

  • Clear UI intent: The OK and Cancel buttons make it immediately obvious that the user is making a decision. There’s no ambiguity about what happens when you close the page.
  • No premature database writes: Unlike a card page bound to a table, a standard dialog with text variables doesn’t touch the database until your code explicitly does so after the user clicks OK.
  • Clean separation of concerns: The calling code handles the setup and result processing, while the dialog page handles the layout and user interaction.
  • Intuitive for users: Compared to having users click an action in an action bar to confirm what they’re doing, a simple OK/Cancel dialog is a pattern everyone understands.

Summary

The StandardDialog page type is a simple but powerful tool in the AL developer’s toolkit. By combining it with the page variable pattern — using Setup to pass data in, RunModal to display the dialog and capture the user’s decision, and getter functions to retrieve the results — you get a clean, intuitive UI pattern for gathering user input. If you haven’t been using standard dialogs in your Business Central extensions, give them a try. They provide a natural OK/Cancel workflow that users understand immediately, and the code pattern is straightforward to implement and maintain.

Picture of hougaard

hougaard