For a long time, if we wanted to get input from the user to confirm something, we used Confirm() method. This method is straightforward – it has two parameters (+ unlimited number of constant values similar to StrSubstNo() method). The first one accepts text shown to the user, the second one (optional) defines which button (OK/Cancel) is chosen as default.
...
if Confirm('Confirm or Cancel?', true) then
Message('Confirmed')
else
Message('Canceled');
...
The biggest issue with this design is that every time we use this method, we have to think about the process as a whole – whether a user action will call the method or whether it will also be called from the system (job queue, APIs, …) process. In that case, we have to think about how the confirmation dialogue should behave during the process with no user input and suppress the dialogue using GuiAllowed() method.
“Confirm Management” module
Confirm management is a new module (it is not really so new; it is available since the first versions of the Business Central). The source of the module is available on Microsoft GitHub.
The module contains two methods GetResponse and GetResponseOrDefault. The difference is what the method returns if Gui is not allowed.
codeunit 27 "Confirm Management"
{
procedure GetResponseOrDefault(ConfirmQuestion: Text; DefaultButton: Boolean): Boolean
begin
if not IsGuiAllowed() then
exit(DefaultButton);
exit(Confirm(ConfirmQuestion, DefaultButton));
end;
procedure GetResponse(ConfirmQuestion: Text; DefaultButton: Boolean): Boolean
begin
if not IsGuiAllowed() then
exit(false);
exit(Confirm(ConfirmQuestion, DefaultButton));
end;
..
}
In that case, GetResponse() always returns false in comparison to GetResponseOrDefault() that returns the default value passed to the method as one of the parameters.
What’s more, there is also the publisher method OnBeforeGuiAllowed() that we can use to manage whether the Gui is allowed or not. It can be used, for example, to simulate job queue runs called directly by the user (admin).