The very first piece of AL Code for Visual Studio Code has just gone VIRAL! GitHub admins see above normal forking of this great branch. Check it out and see what our language of the future looks like!
Microsoft starts teasing us while we eagerly wait for the December PREVIEW.
// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License. See License.txt in the project root for license information.
// Codeunit for creating random greetings
codeunit 70051100 GreetingsManagement
// Get a translated 'Hello World' string.
// Thanks to https://www.bing.com/translator/
local procedure GetHelloWorldText(GreetingNo : Integer) : Text;
case GreetingNo of
0: exit('Afrikaans: Hallo wêreld');
1: exit('Arabic: مرحبا بالعالم');
2: exit('Bulgarian: Здравей, свят');
3: exit('Cantonese: 世界你好');
4: exit('Greek: Γεια σου κόσμε');
5: exit('Korean: 전 세계 여러분 안녕하세요');
6: exit('Thai: หวัดดีชาวโลก');
7: exit('Hindi: हैलो वर्ल्ड');
8: exit('Japanese: ハローワールド');
exit('Hello, World'); // Default to the good old one.
// Gets a random greeting.
procedure GetRandomGreeting() : Text;
If you don’t know what I’m talking about. Get out from under your rock and see some daylight. Microsoft is moving the good old C/AL programming language to “AL” programming in Visual Studio Code with a new compiler.
I already have a whole series of blog posts about this ready since the new compiler has all capabilities to make my dream come true. Design Patterns as templates to be used just like C# templates. The compiler is crazy smart and will be the vehicle to make upgrading more predictable in the future.
As part of the NAV TechDays YouTube channel you can also see the session about the designer as well as the preview in the Keynotes.
If you like reading more than watching, then go to the blog of Arend Jan.
This week after NAVTechDays I started upgrading one of my more complex customers to NAV2017. We have several reasons to do this.
Eventually we want to use the Outlook Add-In for a project next year to improve the sales data and reduce invoice errors.
My first reason was to use Notifications. I had already built something like Notifications in the classic client which was very easy with the Wysiwyg controls and we lost this when upgrading to NAV2016.
Then we got another reason. Job Queues. In NAV2016 they sometimes keep hanging over maintenance jobs in the weekend or during other scheduled or unscheduled system tasks.
Job Queues got improved in NAV2017 and are now part of platform and multithreaded. They came a long way since they ran as a Form with a Timer.
Funny detail is that the system table is not called Job Scheduler just like the first one.
Since we have a huge amount of users in multiple locations and countries and quite a large database we decided to break the upgrade down in smaller pieces and start with a platform upgrade.
This is quite easy and does not take more than a few minutes but during testing I ran into this error message:
“Call to the function ‘LOCKTABLE’ is not allowed inside the call to ‘TryPrint’ when it is used as a TryFunction.”
This made me smile since I actually managed to implement try functions during transactions. I have to fix this but I decided to move that to a later point in time when I do the Application upgrade.
NAV2017 has a new key called DisableWriteInsideTryFunctions which by default is set to TRUE. This is perfect but not when you run a platform upgrade since NAV2016 actually supported this.
The reason not to go for full upgrade is end-user training. The UI of NAV2017 has changed so much and I don’t have time to train all the users in the timeframe I want the platform improvements to work.
It’s not because merging is a lot of work. In NAV2016 we have implemented a lot of events where possible and hooks where there were no events.
You can upgrade Job Queue to the NAV2017 objects quite easily since they are isolated. The only change is in Codeunit 41 where is calls into a Job Queue Codeunit.
If you don’t remove this reference NAV will do an App Crash with no usefull log.
The very first second I spun up the 2017 instance and started testing everything just felt so much more responsive. This was noticable since the database runs on a very slow file system. (To be fixed in December by adding more HP)
The session high on my list for NAVTechDays was this one. I ended up having to miss it because I got stuck at our booth.
This was the 3rd video I watched from NAVTechDays and definately one of the the most interesting ones. I never realised Microsoft had made such big performance improvements to the core stack that on-prem customers would benefit from.
The reason I love NAV is because its simplicity. Something I felt was getting lost last few years by adding components like PowerShell and Azure.
Saas takes all of this away and makes NAV simple again. I will blog more about this in following blogs as I will continue to explore NAV2017, Dynamics 365 and AppSource in my new role as CTO of the Dynamics App Alliance.
When Microsoft Dynamics NAV 2017 was released a few weeks ago there were some issues with downloading. Some MVPs have blogged workarounds. The issues were related to the FTM (File Transfer Manager).
This Microsoft website explains the issue.
Good news I heard at NAVTechDays was that the issue seems to be resolved and I checked this morning and downloaded W1 RTM without issues.
I’m guessing that the FTM was completely removed but I am not sure. Maybe someone from Microsoft reading my blog can comment.
Anyway, I thought I should share this good news on a windy Sunday morning while updating the Microsoft Dynamics Programming book for NAV 2017 for you.
Last week, before going to NAVTechDays I was asked to teach a ForNAV class in Switzerland. NAV2017 was just released so I decided to use that for the examples.
While doing some preparation I ran a few reports and it looked fine until I realised I could not design reports from the Windows Client anymore.
This is a very popular feature of the product where you can design reports as an end user without having to go through the development environment as long as you have access to the ForNAV Designer.
However, when I tested this earlier the “Open Designer” did not show up and I sent an email to my colleges in Denmark, not realizing I was going to confuse the heck out of them and waste a good portion of their time.
Microsoft introduced Application Area as a new property in NAV2017 and if you just play with it without reading documentation it kinda looks as if it is not doing anything.
The reason for this is it’s architecture being hybrid between MetaData and AppData. This is kinda weird for a NAV property.
If we search for Application Area in the Windows Client we find this page
By default these values are blank
When we do a where used of this table we find 86 usages. Most of them pages and one in Codeunit40 LogInManagement
When we use GoToDefinition and end up in the table ApplicationAreaSetup again we can see a new keyword.
This new keyword takes a text string that needs to be in a specific format using the # character. It uses the fieldnames in the setup table.
The result of this is kinda like the Yuck in the Design Patterns session in NAVTechDays. The fieldnames in the application must match Metadata in the tables. In order to change the behavior of this feature everything is hardcoded.
So we end up with application areas #Basic, #Suite, #RelationshipMgmt, #Jobs and #FixedAssets.
Yet if we look into the pages we seem to have #All as the most popular value. More than 1000 page controls have this value.
It seems that #All is a hardcoded value somewhere. Maybe Erik Hougaard can reverse engineer this in the engine.
At first it seems that this property is not a mandatory property. If I don’t populate it nothing goes wrong until…
When you open the Company Information page in NAV 2017 you can see a new option. User Experience. You can set this to basic and suite. But when installed the value is blank which is not a selectable option.
This “field” which is not a real field but the return value of a function is a real “WTF” experience. After you set this to Basic or Suite it looks like you cannot go back. Let’s try this and rerun our report.
Now the “Open Designer” option is gone. This is because I just started to use ApplicationAreas. Let’s look at the Application Area page.
When one of the flags in the setup table is checked, ApplicationArea becomes a MANDATORY property and all of my bespoke objects fail to work.
This feature is implemented because NAV2017 and Dynamics 365 for Financials share a code base but it means that EVERY SINGLE NAV 2017 customer can make his ENTIRE customizations disappear if someone forgets to put #All as a value in EVERY SINGLE control.
It took us more than a week to figure out what was wrong with the report. Not that we spend a week on it but my ForNAV colleagues could not reproduce it and we ended up looking at it at NAVTechDays.
We immediately took it to the Microsoft experts. They recognized the problem and told us they would look into it.
The reason I’ve put this on my blog is to avoid our entire NAV ecosystem wasting as much time as we did.