In the last example I put online, we've noticed that it was difficult to achieve a good separation of concerns in the front end if we are building UI directly…
Now that you are done through this mouthful of the title, you may recognize that it’s the method you invoke when you want to run a control add-in trigger in…
This post has been long overdue. I’ve had it in my to-do list for nearly four years now, but it always ended up in the not today category. Funny how many times I’ve implemented it already, and how many times I’ve presented this, and I never ever found a few minutes to create a demo repository and a blog to come with it. So, here we go.
Control add-ins support packaging script, stylesheet, and image files. This could make you think that you cannot include web fonts. But that would be wrong. If you read my blog post about abusing images to load HTML files, then it might give you some ideas. Yes, you can use the same trick to load web fonts or just about any other external resource.
Let’s take a look how to include a web font, and let’s use Font Awesome as an example. Because it’s just awesome.
Happy new year everyone! Last year was a bit slow for me, until the very end, when I churned out a year’s worth of posts just in two days. I hope this year to be a bit different, and let me kick-start it with a concept I’ve been playing with recently.
If you are into control add-ins development, chances are you’re familiar with my Visual Studio Project Template for control add-ins. It’s cool because it allows you to deploy all of your changes all the way over to NAV just by pressing F6. But it sucks because it’s based on Visual Studio, which is so… not 2019. It’s true, Microsoft never prescribed exactly which tool you should use to build your control add-ins once you’ve created the interface. It was entirely up to you. For me, Visual Studio used to be the tool of choice because in there you create the interface, and then why not just create everything in there.
But recently, I thought – why not using VS Code to develop control add-ins “v1” (that is: the control add-ins that work in pre-AL, pre-extensions “v2”, pre-NAV2018/BC environments)? If you, like me, still have to do those from time to time, but absolutely want to use VS Code instead of Visual Studio, then this post is for you.
And then I remembered gulp.
It’s funny, gulp should have been the first thing to cross my mind. But, while I knew it was there, I never did anything with it. But, how complicated can it be? It turned out, I was able to replace all of the automation I had earlier into one nice gulpfile.js and turn my entire development experience completely upside-down. It’s that good.
So, I decided to share a little bit of my learning path, lessons learned, hints, tips, tricks, and all else in a series of blog posts about how to automate control add-in development using gulp. This is the first post in the series of an unknown number of posts to follow up.
Disclaimer: this particular post is not a NAV 2018/BC/AL. This is (mostly) for pre-BC control add-in developers. However, a lot of gulp concepts I’ll talk about are readily applicable to AL and BC world.
The last of the NAV TechDays 2018 demo series comes with a little story.
And that was it! An amazingly cool demo that shows how you can do really cool stuff that falls beyond the visual realm.
Okay, I’ll calm down a bit. Keyboard shortcuts? Seriously? Well, unfortunately, yes. In NAV/BC web client (universal client included) there are almost no keyboard shortcuts. Microsoft is working on some improvements here, but the important thing, allowing developers to bind specific keyboard shortcuts to specific actions, is still conspicuously missing from NAV/BC.
So, I did this demo.