Vjeko.com

The last of the NAV TechDays 2018 demo series comes with a little story. While Waldo and I were preparing the “Evolution of the Titan” session, on Sunday before the conference, we were brainstorming the ideas of what would constitute a cool non-visual JavaScript demo. I wanted to showcase the things that JavaScript can do for you in control add-in context, but a less obvious thing. Everyone is expecting to see some cool visual demos, but I wanted to point out the vast possibilities in the non-visual area. Then Waldo asked me: can you make it run an action on a keypress, like post a document…

One of the more effective, and probably completely unexpected, demos at Waldo’s and mine NAV TechDays 2018 session was the user profile picture demo. I say “completely unexpected” is that it shows something that you normally don’t expect from control add-ins. When hearing “control add-in”, most developers (but also most Microsoft people) have in mind a visual control that visualizes some data from NAV/BC and possibly allows you to interact with (C/)AL through that piece of UI. However, there are many other things possible, like having a completely non-visual “controls” that tap into the functionality…

Eric Sevareid famously said that the chief cause of problems is solutions . The same applies to the HTML trick I blogged about yesterday. As soon as you solve the problem of using HTML directly in your control add-ins, another problem arises: what do you do with actual images your control add-in includes? This post explains how to solve that problem, and how to make it possible for your control add-in to both use HTML for defining UI and use relative control add-in paths to images. Let’s dig in. Imagine you had a control add-in with this script: … that shows this: Now, you fix…

I usually post my NAV TechDays demo stuff for you to use and abuse, and this year won’t be an exception. There are three changes, to previous years, specially the last year. First, you won’t need to wait until New Year’s Eve for me to post my stuff. Second, I’ll blog each of the demos individually, because of the third reason. Third, I don’t want to merely dump my code here with a big fat disclaimer; no – I’ll dump it with a big fat disclaimer and some explanations about what the code does and why. So, here we go, the first demo (actually the second, because I already posted that Muppet Theme…

This will be my last post in the “JavaScript for (C/)AL Developers” series today. If I continued blogging about nearly pure JavaScript stuff, you could reasonably ask if this is in fact an NAV blog or a JavaScript one. It’s still NAV, and while the stuff I am about to write about is purely a JavaScript concept, I find it highly relevant for any control add-in developer. So, hold my beer, and bear with me for another one. One of the complaints I often hear about JavaScript is that in JavaScript there is no encapsulation. This is almost completely true, except for the fact that it’s entirely false…

I am on a spree today. The number of topics I wanted to blog about has accumulated, and I just decided to dump the stuff over here while I both feel the motivation and have time for blogging. However, in this hurry, I forgot to add some important content to my previous post . First, I forgot to mention that the example of my preserve-jquery script trick can be found in this github repo: https://github.com/vjekob/controladdin-html That’s the demo I blogged about earlier today, except this time it has two more branches: Branch “problem”: showcases how a problematic script can break your…

In my previous post , I’ve written about the situation when you (or somebody you trust) redeclares the $ variable, thus inadvertently breaking all your jQuery code. I’ve also explained how to remedy for it inside the code you write by applying the Immediately Invoked Function Expression (IIFE) or Self-Executing Anonymous Function pattern. However, is there anything you can do to prevent anyone from trampling over $ or jQuery variables in the first place? As I said in my last post, yes, and no. Let’s take a closer look at it. Redeclaration As you know by now, any variable in JavaScript…

First, a disclaimer. This post is written for (C/)AL developers who are struggling with JavaScript, who copy and paste JavaScript code from Stack Overflow right into VS Code and are happy when it works, and confused when it doesn’t. Still, if you are not a (C/)AL developer but want to learn a bit of JavaScript yourself, this post is not at al about AL, it’s purely about JavaScript, and about demystifying a piece of it that JavaScript developers take for granted, and that developers with experience only with simpler languages (such as AL) find confusing. Now let’s jump into the point. A friend…

One of major limitations of control add-ins is not being able to define HTML. It seems so unbelievably unbelievable, that anyone looking at it from the outside of the NAV/BC playground may say “obviously, you must be missing something!”. But I am not. The one thing that you would expect to find first when defining a control add-in (and control add-ins in NAV/BC are nothing more than pieces of HTML that live within the allocated area of your browser real estate) is to be able to define the HTML. And yet, you can’t define it. The only way to show any UI from your control add-in is to procedurally…

One of major limitations of control add-ins is not being able to define HTML. It seems so unbelievably unbelievable, that anyone looking at it from the outside of the NAV/BC playground may say “obviously, you must be missing something!”. But I am not. The one thing that you would expect to find first when defining a control add-in (and control add-ins in NAV/BC are nothing more than pieces of HTML that live within the allocated area of your browser real estate) is to be able to define the HTML. And yet, you can’t define it. The only way to show any UI from your control add-in is to procedurally…