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