How to let users choose field(s) properly

by Jul 12, 2021AL Language

Home 9 Development 9 AL Language 9 How to let users choose field(s) properly

When some complex functionality is developed, it is sometimes necessary to let users choose a specific field. This can be required for field permissions, mapping imported values or any similar process.

Earlier, the usual way was to create a link on the Field table (for example “Field”.”No.” WHERE (TableNo=FIELD(Table ID))). As you can see, you have to first specify (let the user choose) the table. That means that the user has to use two lookup pages. Furthermore, if you want to let users choose more than one field, the script had to be programmed much more complicated way.

However, with all the new changes to best practices that Microsoft has done during the last two years, there is a new way how to let users choose fields properly. All needed is included in codeunit 9806 “Field Selection” (codeunit 9807 “Field Selection Impl.”).

We only need to call method Open(var Field: Record “Field”): Boolean and the system will do everything automatically. The method returns true when a field is selected, false otherwise. The selected field is returned as a selected record of the Field record parameter.

local procedure LetUserChoose()
var
    Field: Record Field;
    FieldSelection: Codeunit "Field Selection";

    SelectedFieldMsg: Label 'Field %1 in table %2 of type %3 has been selected.', Comment = '%1 - Caption of the field, %2 - Caption of the table, %3 - data type of the field';
    NoFieldSelectedMsg: Label 'No field has been selected.';
begin
    if FieldSelection.Open(Field) then
        Message(SelectedFieldMsg, Field."Field Caption", Field.TableCaption, Field.Type);
    Message(NoFieldSelectedMsg);
end;

If we look at the implementation in more detail (codeunit 9807 “Field Selection Impl.”) we can see that some of the fields are automatically excluded from selection – already removed fields (Removed-Obsoleted) and fields that are disabled.

local procedure HideInvalidFields(var "Field": Record "Field")
begin
    Field.FilterGroup(2);
    Field.SetFilter(ObsoleteState, '<>%1', Field.ObsoleteState::Removed);
    Field.SetRange(Enabled, true);
    Field.FilterGroup(0);
end;

Another interesting thing about this functionality is how the selected field (or fields!). All of this depends on the Field record parameter provided in FieldSelection.Open(var Field: Record “Field”): Boolean method. It works differently with Temporary and Non-Temporary records.

If you provide a Non-Temporary Field record, the selected field(s) is returned filtered using the SetSelectionFilter system method. On the other hand, if you provide a Temporary Field record, returned variable contains unfiltered results that contain only selected field(s).

Of course, you can filter fields that will be shown to the user – by applying filters on the Non-Temporary Field record or by inserting only specific fields into the Temporary Field record.

procedure GetSelectedFields(var SelectedField: Record "Field")
var
    "Field": Record "Field";
begin
    if SelectedField.IsTemporary() then begin
        SelectedField.Reset();
        SelectedField.DeleteAll();
        CurrPage.SetSelectionFilter(Field);
        if Field.FindSet() then
            repeat
                SelectedField.Copy(Field);
                SelectedField.Insert();
            until Field.Next() = 0;
    end else begin
        CurrPage.SetSelectionFilter(SelectedField);
        SelectedField.FindSet();
    end;
end;

Side note: the name of the field’s table is shown only when the fields are from more than one table. Otherwise, the table name column is not shown.

Recent Articles from the category

Field Level Permissions (Restricted Fields)

Field Level Permissions (Restricted Fields)

I just add a new project to my GitHub repositories. It is a new extension for Business Central that extends security functionalities with field-level permission. Using this extension, users are able to define who can or can not change specific fields in any table in...

read more
Returning complex types in AL Language

Returning complex types in AL Language

In Microsoft Dynamics 365 Business Central 2021 w1 (released in May 2021), a profound change was introduced to ways how we can design our applications Until this version, the only way to return complex data types (like records, codeunits, Lists etc.) was using the var...

read more
Import various file types with Interfaces

Import various file types with Interfaces

A few weeks ago, I described a solution for importing an Excel file to the Business Central using Excel Buffer in AL Language (see here). In today's article, we will look at how to build a more complex solution that can be used for file imports without the needs to...

read more
How to import Excel files using Excel Buffer

How to import Excel files using Excel Buffer

Last week, I saw a question about importing data from Excel file to Business Central using AL Language. A few years ago, the only solution was to use DotNet integration. However, with the Business Central, there is a much quicker and better approach. All functions for...

read more