Category Archives: Design Patterns

They are the smaller elements that give the application the characteristics people know and are familiar with. By implementing Design Patterns you create familiarity for users across the application. Examples are Number Series, Address Integration and Blocked Entity.

Step 3 – Wizards | ForNAV App Building

Wizard pages are working on a revival from being almost forgotten. They were first introduced as form objects in Navision 3.0 as part of CRM. I instantly fell in love and started to create them for my own add-on.

Wizard pages have a few great advantages to normal pages and let’s go over them.

  1. Save Button – Even though it is not called “Save” the Wizard page is one of the few options in NAV you have to populate data, validate it and cancel the operation without a hassle.
  2. Overview – Essentially Wizard pages have fast tabs just like Card pages but the tabs are only displayed one at a time giving a clearer overview
  3. Validation – Wizard pages allow the programmer to clearly validate the contents of each fast tab before continuing to the next fast tab. Much more precise than normal database validation since with a wizard you can asume, program, for a really specifical order of entry.
  4. Explanation – On each page (tab) of the wizard you can write half a bible explaining to the user what to do. Be careful not to over do it since people these days are not used to sit down and read text anymore.

Continue reading

The “Handled” Pattern

If there was a Pattern of the year award, last year the Arguments table would have won. The year before the Hook pattern. Or maybe that was the year before.

This year in my opinion it is the Handled pattern by Thomas Hejlsberg in combination with Events. It is not yet published by Microsoft on the wiki, but let me try to explain how it works and why I like it.
Continue reading

NAV2016 CU1 | The AltSearchField field property does not work as documented

Whenever I teach a class I always talk about boat anchors and my favorite one is the AltSearchField property.

Luc van Vugt describes it on his blog:

It is one of these features that we inherrited in the Windows version from the Dos version, but it never worked in RTC or other modern clients. This is why I was surprised to see this in the list of fixes for CU1 of NAV2016:

376291 The AltSearchField field property does not work as documented.

After investigation it looks like Microsoft removed the property from the options in the Development Environment.


So this is a boat anchor that is now fixed. However…

If you export the G/L Account table to txt it is still there.


So it is actually a hidden property.

Thank you Microsoft for starting cleaning up NAV!

I have to start looking for a new favorite boat anchor.

Using Argument Tables | Introducing Overloading in Dynamics NAV

Last year I did some videos about organizing code in Microsoft Dynamics NAV which I put on my YouTube channel. I wanted to do more, but got occupied by writing a book about learning dynamics NAV patterns and organizing a global set of classes around this subject.

Let’s continue where we left off and discuss the possibilities and challenges of implementing the arguments table.

Let’s go into it.

At the end of this blog you will be familiar with the Arguments table pattern, why we need it in Dynamics NAV and what are possible negative side effects.

Problem Definition

Within our C/AL programming language and programming in general we have some challenges.

Using to many arguments in a function

When creating functions we sometimes need a lot of parameters to give the information we require. Sometimes these parameters are optional, only required in some scenarios. This makes calling them quite hard. The code becomes less easy to read, sometimes spread across multiple lines.


Hard to change signatures

When refactoring code it is hard to change signatures of functions when they are called in many places of the system. Think about the Functions that create reservations for example. When changing the signature of these function you might end up changing and endless chain of codeunits.


No Function Overloading in C/AL

Our beloved language does not support overloading. What is that? I had to look it up too the first time. Overloading means creating functions with the same name and meaning that take different parameters effectively allowing you to be more flexible in your code.

For example creating a new DateTime in DotNet can be done in 12 different ways with different parameters effectively giving the same result, a DateTime.


Duplicating Option Definitions

Lastly, when calling functions that take an option field as parameter we have to duplicate the option value in order to make the code easy to read. And option values are hard to maintain anyway.


These challenges can be solved by grouping commonly used arguments in a single table and use that table as the parameter of a function. This is effectively using a table as a class.

Let’s look at some examples of candidates in our product

The legacy code of Dynamics NAV is full of examples, but let’s discuss two that you are bound to hit if you start working with the product, even if you don’t deep dive.


This function in codeunit 7000 is called to calculate a sales price for an Item. It uses 10 parameters.


This function in codeunit 365 is called to format an address in the system

Changing the signature

Imaging adding a field to this function, or change a datatype. The amount of code affected is pretty big and if you need to parameter only for one specific case you end up changing a lot of code for no purpose.


Fortunately the compiler finds all instances where the function call is incomplete, but that does not mean we should use that to change all of them.

Let’s also make sure we understand that the sheer fact that NAV legacy code has these functions it is ok to do so. It does not match the basic principles of clean code.

The Argument Table

So the solution is to create a single table that holds the contract for the function. This would be similar to creating a class in DotNet and using that class as parameter.

When we add new fields to the table, we effectively do not change the signature of the function hence this acts as overloading allowing optional parameters to change the behavior of the code.


Examples in Standard Dynamics NAV

What if I told you that this one of the oldest patterns in Microsoft Dynamics NAV, dating all the way back to good old Navision Software. Would you believe me? I guess not, but it is true.

All codeunits that are used to post Journals are effectively argument functions. We use the Journal Line as an argument table to call into the posting routine. Imagine the effect if posting routines had all these fields as parameters.


When we call one of these codeunits nested inside another transaction we never actually insert the journal line in the database. We merely use the record variable as a placeholder in memory for the data.

Side effects

Although in my personal opinion the arguments is one of the greatest patterns to write clean code, there are some side effects

First off we need to write code to populate the arguments table. This requires us to write extra code we don’t need if we just call a function with let’s say 10 parameters. It does make the code cleaner and makes it intention easier to understand.

Also, the fact that the compiler does not catch adding a field to the table as a signature change can be a downside. Who has not abused this feature as “where used”. We would really need where used in order to perform a risk analysis when adding arguments.

Last but not least, one of the basic principles of events will be broken. The new events in NAV2016 have a built in warning system if a parameter that I inherit no longer exists. This mechanism does not understand if I delete a field of an arguments table. The extensions have the same challenge.


Let’s look at an example. In NAV2015 the development team decided to implement email as an arguments table. This is table 9500 Email Item.

This table has all fields we need to send emails, as well as functions to send the email. The validation logic of the fields can be used to perform checks on the values. How nice and clean is that.


The arguments table is used in Codeunit 260 Document Mailing. Here you can see the coding that is required to use an arguments table.

A new, nice and clean way of writing C/AL code.

Naming Recommendations

When using arguments tables, I recommend adding the keyword “arguments” to the name of the table. This makes it one of the only, if not the only plural table name in Dynamics NAV.

Licensing Considerations

In essence Argument tables can be outside of a customer’s license file since we never insert data in the SQL Server database. However, when you want to use functions as methods of the arguments table it needs to be licensed. Reason for this is simple. The licensing engine is not aware that you want to run code that is tied to a temporary table, you might for example call code in a Production Order when running Business Essentials licensing. To make this work, Microsoft first needs to add a table type “temporary” to the properties

Want to know more?

I will create a video on this too soon. The Arguments Table is also part of my new book.

Learning Dynamics NAV Patterns

NAV2016 | My first extension (UPDATED) | NAVUG Summit

UPDATE: Download the files and script from the new Mibuso

This blog is written from Reno Nevada where the folks from the NAVUG content committee asked me to talk about how to integrate add-ons with NAV. This session was intented to inspire people to think about alternative approaches to the traditional raw source code modification.

Part of the session was about Web Services and the new Eventing framework. I also wanted to show how the new extensions allow you to enhance NAV without customisations. Hence I had to figure out how this works.

Step 1 – Create the Delta

The first step is to have Delta files that are within the limitations of the extension framework. These are New tables, Pages and Codeunits and adding fields to tables and pages.

Reports, XMLPorts and Query objects are not supported.


Once we have the delta files we need aditional PowerShell

Step 2 – Manifest

The extension needs an XML file that tells us what the version of our extension is, the name and the publisher.

The easiest way to have that is to create it with PowerShell


The XML looks like this


Step 3 – Create NAVX File


That is how easy it is to create an extension.

Step 4 – Publish the Extension

Now we need a new clean database to use it in. So in PowerShell we move to a new service tier.


This makes the extension available in our database, but it is not activated

Step 5 – Install

The last step is to install the extension.



Now the extension is available in our database.

You can hopefully download this example from the new Mibuso website soon.

Here are the commands for copy/paste

New-NAVAppManifest -Name “NAVUG Summit” -Publisher “Mark Brummel” -Version “” |

New-NAVAppManifestFile -Path “C:\Users\marq\Documents\DynamicsExt90\Manifest.xml”

Get-NAVAppManifest -Path “C:\Users\marq\Documents\DynamicsExt90\Manifest.xml” |

New-NAVAppPackage -Path “C:\Users\marq\Documents\DynamicsExt90\NAVUG.navx”

-SourcePath “C:\Users\marq\Documents\DynamicsExt90\Delta\”

Publish-NAVApp -ServerInstance Clean2016 -Path “C:\Users\marq\Documents\DynamicsExt90\NAVUG.navx”

Install-NAVApp -ServerInstance Clean2016 -Name “NAVUG Summit” –Version


The orriginal post was created with NAV 2016 RTM. Microsoft has now made an upgrade codeunit mandatory. Read here.