Well, control add-ins are not new in NAV 2016, they have been around for a long time now. But, they have been improved and this blog post is about these improvements.
Of course, the improvements are exclusively in the Web client framework, not the Windows client, and I am educated-guessing here that we won’t really see many improvements in the control add-in framework for Windows in the future. Why would we? All control add-ins should target all clients and use the Web framework, anyway so the case for Windows client is getting weaker and weaker.
So, let’s take a look at what kind of improvements there are for the Web client framework. First of all, there are new Manifest.xml properties.:
- MinimumHeight
- MinimumWidth
- MaximumHeight
- MaximumWidth
- VerticalShrink
- HorizontalShrink
This is on top of requested width/height and vertical/horizontal stretch ones we already had since 2013 R2. The change is not merely cosmetic and it does influence the behavior of the control add-ins quite a bit. Earlier, any control add-in got it’s reserved piece of real estate and it could never shrink to a smaller size, no matter what. Also, if allowed, it always stretched as far as it could.
In Microsoft Dynamics NAV 2016 the requested height and width determine the initial size, but you can then control whether, and how far exactly, it can stretch or shrink. The framework uses these properties to define the inline styles for the IFRAME element.
While nice, these new properties do not really solve the problem of sizing. The biggest issue is that the manifest is hardcoded, and allowing resizing to fit the constraints of the actual device is okay, however you may still want to have different minimum/maximum sizes or shrink/stretch behavior depending on which client you are in and on which device. Thus, you either have to provide multiple different control add-ins (each with different hardcoded dimensions), or you have to pull some JavaScript tricks to resize the control add-in later on (and have Microsoft frown upon them because they are unsupported).
If I could have a say in the matter, I’d drop those properties from the manifest altogether and have built-in properties on the control add-in control variable accessible through C/AL, or keep the properties in the manifest, and still allow us to access them from C/AL at runtime. I’ll make this suggestion for a future release, and let’s see if it happens. I had an improvement suggestion accepted before, so this one might get in, too.
Other improvements include the two new functions for authenticating users, which are currently only useful in the Social Listening context, but you might be able to find some use for them yourself. They are OpenWindowForAuthentication and OpenWindow, and they are undocumented at the time of writing of this blog.
There are also significant improvements to two existing methods. First, the GetEnvironment method now returns more properties. New “Platform” property tells you whether you are running inside Windows, Web (of any flavor) or the Universal app. Quite cool. Also, the “DeviceCategory” property now adds a new value (2) indicating you are running inside the Phone client. Combining Platform and DeviceCategory, you can know exactly which environment you are in, and this can help you make relevant styling or behavior decisions in your JavaScript code.
And finally, my absolute favorite improvement, which also went silently into the framework, is the GetImageResource method. In earlier versions of the framework, this method could only return a png image which absolutely had to have the .png extension. In NAV 2016, you can now retrieve any file type, not necessarily an image, which makes this little inconspicuous function quite versatile. And, on top of everything, we are now free to organize the resources into subfolders of whichever name, and depth. I have already (ab)used this feature in my Directions EMEA 2015 demo.
I’m certainly going to blog much more about this and other features of the control add-ins framework, so stay tuned,.
Hi Vjeko, thank you for the post!
Did you notice that in NAV 2016, using an StringEventHandler to post strings from Javascript to NAV is not supported anymore? I followed recommendations from you some months ago and they worked perfectly with NAV 2015 but not with NAV 2016.
I am was using the method to pass JSON strings over to NAV, do you recommend any other method currently supported in NAV 2016 for that task?
Hm… can you please elaborate, what exactly is not working anymore? Because I have demoed the control add-ins and I am just about to demo them once again in exactly 57 minutes here at Directions US in Orlando – and I do demo events and passing JSON data using events, and it works. Can you paste some js code that does not work and I’ll tell you what to do to fix it?
Yes, no problem!
********** CODE SNIPPET **********
The Interface:
public interface IResourceScheduler
{
[ApplicationVisible]
event ApplicationEventHandler ControlAddInReady;
[ApplicationVisible]
void TransferString(string data);
[ApplicationVisible]
event StringEventHandler SendString;
}
The StringEventHandler:
public delegate void StringEventHandler(string data);
The Javascript:
$(document).ready(function () {
var controlAddIn = document.getElementById(‘controlAddIn’);
controlAddIn.innerHTML = “Hello World”;
Microsoft.Dynamics.NAV.InvokeExtensibilityMethod(‘ControlAddInReady’, []);
Microsoft.Dynamics.NAV.InvokeExtensibilityMethod(‘SendString’, [‘Very String’]);
});
The Manifest:
jquery-1.11.3.min.js
<Script<ResourceScheduler.js
1
1
false
false
********** CODE SNIPPET **********
As you can see I have brought this down to the simplest level. When it is run in NAV2015 everything goes smoothly. When run in NAV2016 I get the following error: Method ‘Page50000.Resource Schedulera58a58ControlAddInReady(number of arguments: 0), with matching argument types.’ not found.
Hopefully this is just a silly mistake by me, appreciate you taking your time to try and point them out 🙂
Wow, I just found the error. It was not at all in the way I was sending strings over to NAV.
The ‘Name’ field in the page you are using cannot contain a space character. When I changed the name of the field that holds the control addin from “Resource Scheduler” to “ResourceScheduler” everything worked as before.
Cheers!
Ah okay, I see this other comment now. Glad that you found the issue and fixed it. Yes – the names can be tricky, you should always follow good naming practice and declare all identifiers without spaces or special characters.
I’m getting the same error (2016 46290) – however I don’t have any spaces in the Name field – (and is driving me crazy).
Any ideas/help? ty
I can’t verify this right now because at this machine I only have NAV 2015 installed, so I am only guessing. This ApplicationEventHandler delegate – in 2015 it is a delegate for a parameterless void method. Is it still the case? What would happen if you would either reference System.Windows.Forms and then use MethodInvoker as the delegate for the ControlAddInReady, or if you declared your own public delegate void EmptyEventHandler() and then used that as the delegate type for the ControlAddInReady event?
Roger that, thank you for the help!
I have created a text editor using some of your methods. I am noticing control addin created with jav that the enter key in the windows client moves to the next control. And they have this Microsoft.Dynamics.Framework.UI.Extensibility.IControlAddInEnterKeyHandler in which I have found to work to prevent this. However, using a java control, how can I use the IControlAddinEnterkeyHandler? DO you have an example. All the best-Kevin
Any Suggestions?
Vejko, have you experienced the annoying warning message “To help protect your security, your web browser has restricted this file from showing active content that could access your computer.” with JavaScript add-ins in NAV?. Everything works fine without warning message if client and server is running on same machine. But if they are separated on two different machines in a network this pops up. Tried all imaginable settings in IE and servers without luck to get rid of it 🙁
No, I have never seen it. Make sure to only reference scripts that come from https, that could solve it.