Control Add-in

My last topic was resident control add-ins . In my video and written blog I’ve explained what they are and how you can quickly have them up and running. However, there was one particular thing I said I generally don’t like – single-instance codeunits.

One of the most common questions I get asked about Control Add-ins is whether you can make a control add-in be always present and able to respond to your calls from AL. In other words: can you have a resident control add-in that you can invoke from anywhere in your AL code. I’ve done a lot about control add-ins.

If you missed my From JavaScript to AL and back: SkipIfBusy live session on January 8, or if you simply prefer to read rather than watch, then this post is for you. As promised, I’ll follow up in writing on all my video blogs, so here we go.

Thanks to everyone who watched my live stream today! The audience wasn’t big, but it’s a very narrow topic, not of broad interest. Still, I am glad I got a few interesting questions that actually introduced my future topics quite nicely. You can find the recording here: As promised, I have published the GetImageResource.js file on my GitHub.

I’ve been absent for a while – sometimes it’s difficult to find time for blogging even when I want it. Anyway… here’s the last post in the introductory series of posts that explain my NAV TechDays 2019 demos. In this code example, I explain the difference between typical development and production build configurations, and I show how to configure gulp accordingly.

After a short absence, I am back. The next lesson in the Control Add-ins Supercharged series I am introducing Babel . “Babel is a JavaScript compiler” , says babeljs.io. So, what’s the big deal, you may ask? The big deal is that Babel will take your super-fancy high-end future-generation JavaScript…

So far I’ve shown how to configure gulp to help you with some basic JavaScript development tasks, such as bundling and minifying, and how to automate builds on every source file change. Let’s now take it to an entirely new level: debugging.

Yesterday you’ve seen how to use gulp to make it do something truly useful: bundling your JavaScript and CSS files. Introducing gulp for the purpose of bundling your files allows you to split your functionality into as many files as you want, but use only a single script and a single stylesheet file from your control add-in.

My last demo introduces gulp, an amazingly simple task automation tool. You’ve seen what it is, how to set it up, and how to create a simple hello-world task. Now it’s time to teach gulp some useful tricks and make it automate the “build” process for the JavaScript and CSS files.

Get ready for the next big step in taking the control add-in development to the next level. Today, I am (re)introducing gulp. I’ve blogged about gulp in the past, but I’ve never really finished that series. Life and work got in the way.