C/AL – Vjeko.com

HelloWorld.al

Post published:November 29, 2016
Post comments:10 Comments
Reading time:3 mins read

Finally. Not quite, but still – finally! We finally get the first public glimpse of future of AL code writing, courtesy of Microsoft Dynamics NAV development team.

As you might know, Microsoft is working around the clock to enable new kind of programming for NAV: using Visual Studio Code instead of Microsoft Dynamics NAV Development Environment. They announced it with due fanfare at Directions US, Directions EMEA, and NAV TechDays, and now the NAV community is biting their fingernails off waiting for Microsoft to actually release the thing.

They said some kind of preview will be made somewhat available sometime in December this year, but for now we have got the first glimpse of the new AL syntax.

(more…)

C/AL internals: Some more invalid object states

Post published:October 19, 2016
Post comments:8 Comments
Reading time:8 mins read

If you have followed the posts about how C/AL really executes in NAV, you know that C# and C/AL can sometimes be in a state where C/AL compiles, but C# does not, causing you some headaches during run time.

However, what might not be obvious is that there are situations where C/AL does not compile anymore (typically due to a changed dependency signature, or due to an object that went AWOL) but C# not only compiles, but also happily runs as if nothing is wrong in the first place.

These situations can be confusing, and after having read my original post, my friend Heinz has pointed out to those situations and asked me if I can explain them. So, here it goes.

(more…)

From C/AL to executable: how NAV runs your C/AL code

Post published:October 6, 2016
Post comments:22 Comments
Reading time:12 mins read

A lot of folks write C/AL and never worry about what happens then. C/AL is written, NAV execute is, the story ends. The same way the story ends when you flush a toilet and the tank refills. How exactly? Who cares.

While understanding the inner workings of a toilet flush tank doesn’t necessarily make you more efficient at whatever it was that made you press the flush button in the first place, having a better understanding of exactly how NAV uses your C/AL code throughout its lifecycle is of arguably higher practical value.

Have you ever wondered what exactly happens to your C/AL code when you write it? How exactly does NAV run that stuff? Does it do any run-time interpretation, or does it compile C/AL into native code that runs on a processor? What does just-in-time compilation mean and does it happen with C/AL? If so, when and why?

If any of these questions bother you, read on. If they don’t bother you, read on because they should bother you. If they don’t bother you because you know the answers, read on still, and then brag by poking holes in my explanation.

(more…)

Gentlemen’s agreement pattern, or handling the “Handled” pattern

Post published:October 4, 2016
Post comments:9 Comments
Reading time:13 mins read

I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.

It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.

Let’s take a look.

(more…)

Decoupling dependencies in C/AL

Post published:September 30, 2016
Post comments:8 Comments
Reading time:12 mins read

Directions US 2016 (yes, 2016, sorry y’all who got the 2017 link in your mailbox) was quite an event. As Directions always is, a lot of people, enthusiastic about this market we strive to thrive in, and about the product we love no matter the limitations we often face when we aim for better, more scalable architectures.

If anything, it reminded me of a long to-do list I have had around for this blog for a while, and I decided to start cleaning it up. The topic of my main session this year was loose coupling of dependencies (I called it polymorphism, because that’s what I’d ultimately like to see possible in C/AL) and I presented two patterns I came up with during my past few years.

Before I present them here on my blog, I wanted to put them in a broader context: loose coupling. So, this is what this post is all about: explaining what loose coupling is, how to achieve it in C/AL, and why you will not want to live without it ever again.

(more…)