Although enums are static lists of values, there is a way to restrict which values can be used. With this post I will show you how to do that, and how you can dynamically set up how this happens.
Didn’t Think it was Possible
I didn’t think dynamic enums were possible but I asked the question on Twitter anyway. The golden tip was a page property called ‘ValuesAllowed’. As I was figuring out how to use this property I thought I’d write this blog post. When I returned to Twitter to post my findings, there were two more links to some other people’s articles in the replies. I’ve since removed much of the details from this post, since they are essentially the same. Go and follow the links in the Tweet replies to read those details.
Both replies cover an essentially hard coded way to restrict option values. I want to take this one step further, where we provide a setup field that is used to manage the choices that you see. Now… I have to say I do NOT like using a static list of options for this purpose. We are still looking at a static list of values, and we are hardcoding what is visible. In my real-world scenario we had to put something in place quickly, and this was indeed a very quick ‘fix’.
Scenario
My actual scenario involved a rather controversial topic, so let’s use a silly scenario instead. We add a field to the Customer table called ‘Dessert Choice’, with an enum type that has 4 values: <blank>, Icecream, Cookies, and ‘Choice Declined’. You need an enum object, a table extension with a field based on the enum, and a page extension to add the field to the Customer Card. Let’s say you want to restrict the ‘Choice Declined’ option. Easy peasy, lemon squeezy, you add a ‘ValuesAllowed’ property to the field on the page extension, and you specify the values that you do want to allow.
In my real-world scenario, my client needed a way to restrict the available options for one company, and provide all of them in others. What we ended up doing was add a toggle to a setup table to turn this restriction on or off.
Show Me The Code
As per usual I was writing and writing, using SO MANY words to describe the situation, and decided to just give you the page extension itself, assuming that you can figure out the fields that I am using.
pageextension 60000 CustomerCardDnStr extends "Customer Card"
{
layout
{
addafter(Name)
{
field(DessertChoice; Rec.DessertChoice)
{
ApplicationArea = All;
ToolTip = 'Specifies...';
Visible = AllVisible;
}
field(RestrictedDessertChoice; Rec.DessertChoice)
{
ApplicationArea = All;
ToolTip = 'Specifies...';
ValuesAllowed = Blank, Icecream, Cookies;
Visible = (not AllVisible);
}
}
}
var
MySetup: Record MySetupDnStr;
AllVisible: Boolean;
trigger OnOpenPage()
begin
MySetup.GetRecordOnce();
AllVisible := MySetup.AllowDecline;
end;
}
Basically you create multiple controls in the page extension for the same field, and you toggle visibility based on a field in a setup table. You could even do this at a record level in a list, by using an InDataSet variable, and putting the code in the OnAfterGetCurrRecord trigger. Again, I’m thinking this should have been done with a table with actual functionality, but this way uses very little code and we had to put something in very quickly.
That’s it, nothing fancy. Not very clever, but useful in my client’s scenario.