tl;dr version: Use GetImageResource. But it doesn’t always just work…

Now I wish that I could claim that I uniquely discovered this neat little trick, but while I will claim that I discovered it with no outside help, it’s obviously obvious enough that I’ve heard a few other people in the channel talk about it since. And how to fix “the bit that doesn’t work” (teaser – see below) is something that might be unique…

Some background: If you follow the instructions for creating a Javascript Add-In (or Dynamics NAV Any Client Control Add-In) you will notice that you are creating three folders within your VS Project: Image, Script & Stylesheet that correspond to three tags (of the exact same name) with the Resource section of your Manifest file. As far as I know (and I have unsuccessfully tried to find any documentation to corroborate this – please let me know if you do) only these three exact tags and folder names are allowed.

The files from these three folders should be included in a zip file that you load against your Add-In, and then will be published with your Add-In whenever they are needed – you don’t need to manually distribute any DLLs or anything else, and all Scripts and Stylesheets will be automatically loaded in the header of the Add-in. So far so brilliant.

But something a few people immediately noticed is that sometimes we want to publish resources that either aren’t any of these types, or they are a Script or Stylesheet we don’t necessarily want to load straight away. The answer seems to be quite simple, put those files into the Image folder (and Manifest tags) instead, and then you can use the GetImageResource Javascript method to get the path of the file you want (did I mention that when the files are published they are renamed so NAV provides some helper methods to find the files you want?).

Great, now I can publish whatever files I want and access them dynamically from my front-end Javascript 🙂 So what doesn’t work?

This is where I realised the importance of testing across clients from the beginning. I do most of my Development and Testing using the Windows Client – because it’s quick and I’m used to it, but the Windows Client and the Web Client treat Control Add-Ins ever so slightly different.

When the “Image” resources get renamed for the Windows Client they just get prefixed with a path and a big number, when they get renamed for the Web Client they also get suffixed with “.png” – no matter what type they are (so you may end up with files “…banner.png.png”, “…logo.gif.png”, “…customJS.js.png”, etc…). The GetImageResource function does return the correct filename and in most cases this will probably be fine, i.e. if load a js file or css file it won’t care about the file extension.

So (again) what doesn’t work?

Well, I wrote this code to open a child window with an htm file I had included with my Resources. (Why? See this stackoverflow)

Javascript
childWindow = window.open(Microsoft.Dynamics.NAV.GetImageResource('ChildWindow.htm'), 'child', "width=500, height=500, location=no, menubar=no, scrollbars=no, status=no, toolbar=no");

With a Windows Client Add-In this works fine, however with the Web Client the browser tries to open a file called “…ChildWindow.htm.png” and decides to treat it as an image rather than html.

So, how did I fix that?

What you can do is get IIS to tell the browser to treat the file differently by adding a Handler Mapping against the request path *.htm.png. I chose a “Module Mapping” using the ServerSideIncludeModule. I’m not sure if that is the best Handler Mapping, but it works. (This module is designed to deal with file types *.shtm & *.shtml which also are files that aren’t exactly htm but should be treated as if they are. On IIS7 this module is not enabled by default, you have to add it to the features of IIS).

And it all works, hurrah! The next bit to test is whether my childwindow will still nicely communicate with the parent window and then back to NAV… a basic Hello World seems to work… maybe I’ll get to blog about it some more, but I’ve just had 10 other projects land on my desk…

Nikolai