Tips & Tricks

Not that I am saying it’s a good thing, but trial and error is a fairly common approach to debugging in the NAV world. We’ve all done it. Heck, even with the comprehensive testability framework built in, we all still do it more often than we’re happy to admit while sober.

In most of my JavaScript client extensibility demos, I develop the whole content of my resource ZIP files inside Visual Studio. When I press F6, magically my NAV gets updated with the latest version of JavaScript that I just wrote. So, how do I do that? Here’s the cookbook.

Some NAV PowerShell cmdlets (such as Import-NAVApplicationObject ) don’t have the -Force switch, and always ask for confirmation regardless of whether you include the -Confirm switch or not. To work around this, append the – Confirm:$false switch to such command.

Switching from C# to JavaScript to develop your control add-ins might get you scratching your head more often that your scalp, or nails for that matter, might be happy with. One of those is overloading. In C#, this is a no-brainer: However, when you want to do that in JavaScript, if you are not a…

While it may be a cold day in hell before we see any TRY..CATCH constructs in pure C/AL, we are all far more lucky when it comes to .NET interoperability. In this blog post I’ll (re)present the same concept I demonstrated during NAV TechDays 2013 last year in Antwerp, because I am quite sure this nifty little trick got lost under piles of other posts on this blog.

When interacting with custom controls on your pages from C/AL, you must be absolutely sure that the control has been instantiated. If it is not, you’ll get an error such as this: The reason why this happens is that C/AL code gets to execute before the page has been rendered, and thus also before the custom controls have been instantiated.

Upgrade projects are lots of fun. They are full of challenges that keep you busy day and night all the time. I have encountered a very interesting challenge on my last upgrade project. The object upgrade process was completed, the data upgrade procedure ready to go, but when we started first tests we realized that the data upgrade execution takes some 39 hours to complete just Step 1.

Thanks to everybody who attended my session at Directions US in San Diego today. It was a pleasure to deliver it, and I hope you enjoyed it as much as I did. It surely would have been much better if I were not running some kind of a flu, but I won’t complain.

Did you ever need to identify the current object type and ID, programmatically, from within the object? For example, detecting the current table ID in a table trigger like this guy ? Or current codeunit ID from inside the codeunit? Why would you need something like this?

Indexed properties are commonly used in C# because they allow a lot of syntactical flexibility, and make the code more readable, and easier to follow. Indexed properties are very similar to C/AL array indexing, except for two important differences: In C/AL, indexer is always 1-based. In C#, indexers are 0-based.