Business Central Musings

With the Dynamics 365 Business Central 2025 Wave 1 release arriving on April 1, 2025, developers get a new tool in their AL toolbox: the ToText() method. This handy function promises to simplify converting simple type values—like integers, dates, or booleans—into text, cutting down on Format function workaround. But as we’ll see in the code below, it’s not a free-for-all: try using it on an already-text type, and you’ll hit a compile-time error.

The ToText() method is all about efficiency and clarity. It works like a charm on numeric types, dates, and more, turning them into strings with a single call. In version 26’s Base App, you’ll spot it teaming up with TextBuilder a lot—think dynamic string-building for logs, messages, or reports. But there’s a catch: if your variable is already text (like a Text, Code, or even DateFormula), AL throws a compile error. It’s a smart design choice to keep your code lean and intentional.

Let’s dive into a sample from my latest experiment—a codeunit that puts ToText() through various use cases:

enum 50100 MyEnum
{
    Extensible = true;

    value(0; " ") { }
    value(10; "A") { }
    value(20; "B") { }
    value(30; "C") { }
}

codeunit 50100 TestToText
{
    trigger OnRun()
    var
        BI: BigInteger;
        B: Boolean;
        CodeVar: Code[10];
        DateVar: Date;
        DF: DateFormula;
        DT: DateTime;
        F: Decimal;
        D: Duration;
        G: GUID;
        I: Integer;
        En: Enum MyEnum;
        T: Text;
        Info: ModuleInfo;
        guid: Guid;
        TB: TextBuilder;
    begin
        BI := 10;
        Message(BI.ToText()); // Outputs: "10"

        B := true;
        Message(B.ToText()); // Outputs: "true"

        CodeVar := '1234567890';
        //Message(CodeVar.ToText()); // Compile error: Code is already text

        DateVar := DMY2Date(1, 1, 2020);
        Message(DateVar.ToText()); // Outputs: "01/01/20"

        Evaluate(DF, '<1W>');
        //Message(DF.ToText()); // Compile error: DateFormula not supported

        DT := CurrentDateTime();
        Message(DT.ToText()); // Outputs: e.g., "03/20/25 10:15:30 AM"

        F := 0.01;
        Message(F.ToText()); // Outputs: "0.01"

        D := 10;
        Message(D.ToText()); // Outputs: "10"

        G := CreateGuid();
        Message(G.ToText()); // Outputs: e.g., "550e8400-e29b-41d4-a716-446655440000"

        I := 10;
        Message(I.ToText()); // Outputs: "10"

        // enums
        //Message(MyEnum::" ".ToText()); // Compile error: Enum not directly supported

        T := 'Hello World';
        //Message(T.ToText()); // Compile error: Text is already text

        // TextBuilder
        TB.Append('1');
        TB.Append('2');
        TB.Append('3');
        Message(TB.ToText()); // Outputs: "123"
    end;
}

This codeunit tests ToText() across a range of data types. It runs smoothly with BigInteger, Boolean, Date, DateTime, Decimal, Duration, GUID, and Integer, outputting text every time. The TextBuilder example is a mirror use case of what you can find sporadically through Base App (ver. 26.0).

Check Table 5384 local method GetAllValidFields in Base App for a Microsoft example of usage of ToText() method for TextBuilder data type.

But those commented lines? They’re where I hit compile errors. CodeVar (a Code type), T (a Text type), and DF (a DateFormula) all ran into compile errors because they’re already text or not fully supported. Even the Enum use of ToText() failed—seems ToText() isn’t quite ready for that one yet.

Takeways

1. ToText() is a powerful ally for converting non-text types, especially when paired with TextBuilder for dynamic outputs—a combo you’ll see all over Base App.
2. Just steer clear of using it on text types, or you’ll be debugging a compiler complaint instead of shipping code.

A quick demo below: