AL for Dinosaur Developers: the Page Management Codeunit

After the success of my previous article (if you missed it you can find it at this link), today I want to give another arrow to the bow of all those developers who for years are used to writing the same code over and over again.

Today’s topic is the Page Management codeunit. As you can guess from the name, this codeunit handles the opening of pages. For years, we’ve been accustomed to opening pages with instructions PAGE.RUN or PAGE. RUNMODAL by putting as the first parameter the page you want to open (I recommend you use PAGE::”page name” for a better readability of the code; I am horrified when I still see the page numbers directly) and as per the properly filtered table. Sometimes the first parameter would be left with 0 which, in combination with the table of the second parameter, would open the page that may have been specified in the table’s DrillDownPageId property.

This notation is still fine today, but how many times has it happened to you (to me often, and the more the years go by, the more frequently 😅 it happens) that you don’t immediately remember the tab page that opens, for example, a purchase order?

This is where the Page Management codeunit comes in. In fact, by filtering the Purchase Header table with Document Type = Order, then calling the PageRun function and passing the filtered table, the codeunit will take care of opening the correct page of the order. Below is an example of what I’m illustrating in words.

The function, from which this code snippet is taken, did other things as well, but the one I want to draw your attention to is on the PageRun call. The Purchase Header table is filtered only by document type = order.

Also note the second part of the statement (the one with else), you’ll notice that if you need to open a list page, you can use the GetDefaultLookupPageIDByVar function that returns the page number of the table’s LookupPageId property. In fact, remember, you can use the PageRun function to open tab pages when the record handles different types (and therefore several pages).

If you use the Visual Studio code extension called LinterCop written by the excellent Stefan Maron, you will get a warning on the following tables:

IdName
36Sales Header
38Purchase Header
79Company Information
80Gen. Journal Template
81Gen. Journal Line
91User Setup
98General Ledger Setup
112Sales Invoice Header
131Incoming Documents Setup
207Res. Journal Line
210Job Journal Line
232Gen. Journal Batch
312Purchases & Payables Setup
454Approval Entry
843Cash Flow Setup
1251Text-to-Account Mapping
1275Doc. Exch. Service Setup
5107Sales Header Archive
5109Purchase Header Archive
5200Employee
5405Production Order
5900Service Header
5965Service Contract Header
7152Item Analysis View
2000000120User

Now that you’ve read this article, will you use this codeunit? I’m sure so, also because I find that the code is much more performing and elegant when you use the tools that our beloved AL Language and Business Central provide.

Leave a Reply