AL for dinosaur developers: the Confirm Management codeunit

This post is inspired by a session, which I attended at the last Directions EMEA 2023 in Lyon, about the news of the AL language aimed at the “old” Nav developers (jokingly called dinosaurs). This session, held by the legendary Arend-Jan Kauffmann and Eric “waldo” Wauters, was aimed at those who have always developed in Nav and told the audience about the opportunities that the AL language offers for Business Central.

I participated in it, basically, because of the admiration I have of these active members of the community, but also to see the faces of those who were in the audience, because some, indeed, were amazed by the enormous potential of the language and also surprised to see that something they did before can now be done differently and perhaps even better (and by better I mean optimized).

I often go to code written by others and notice that there are old C/AL legacies. I certainly don’t define myself as a young man from Business Central (and before Nav) I’ve been working on this management system for almost 20 years, but I also don’t feel so old (at my age Gianluigi Buffon still played football) to remain indifferent to the new features introduced by Business Central and the AL language.

One of these is how to handle confirmation messages for user actions, so-called Confirm.

We’ve always been indoctrinated that user interaction messages were handled with code like:

IF CONFIRM(‘Some question?’, FALSE) THEN

// do something

With Business Central and AL language, we can manage all our Yes or No question-answered interactions via codeunit 27 “Confirm Management”. This codeunit has only two functions, a GetResponseOrDefault call that handles with the default value passed as a parameter if the code containing it is, for example, executed under NAS (so it handles the IF Guiallowed statement); while the other GetResponse function returns FALSE if the function is invoked without UI.

In fact, this codeunit is designed to be called externally. The dirty work is done by the other codeunit “Confirm Management Impl.” which is identified with ID 27.

An example of code that we can do, using the “Confirm Management” codeunit, is like this:

Basically, with this code snippet, we pass the message contained in the WhseShipShowWarningQst constant to the GetResponseOrDefault function and then pass false, as the default value if the function is executed under NAS.

With this codeunit we can forget about “stuffing” our software with the IF GUIALLOWED statement, it’s still one less line of code to write and more time to think about the next one to write 😉

This post has dealt with a topic that is simple in itself, but it also wants to make the Business Central software developer think: the management system has changed, the interface has changed, the changes have been both for users and for those who have to do training, but the change is also under the hood; so the modern developer of Business Central must not remain a dinosaur, but evolve into something different.

Leave a Reply