Drag and Drop File Upload for Microsoft Dynamics NAV 2013 R2

Yesterday evening I spoke at Dutch Dynamics Community event, on invitation by my dear friend Luc van Vugt, and the topic was control add-ins for NAV 2013 R2. Of course, this automatically meant that the audience should see more JavaScript code than C# or C/AL, and that it should be something both fancy and useful.

So how about this: you drag and drop a file onto an NAV page, and the file is automatically uploaded and stored in a BLOB field in the NAV database? And yes, it does the same no matter if you call it from the Windows or the Web client. And yes of course, no external components or dependencies needed.

As I promised, I would make all the source components available for download after the sessions, and if you just want to take the components, here they are, ready to download, install and abuse:http://vjeko.com/wp-content/uploads/2014/03/DragDrop.zip

If you want to know how this thing works and why, read on. Otherwise, just download the thingy, install it (the instructions are included with the file) and abuse it to your fancy.

DotNet Quick Tip: Accessing members with invalid names

A friend asked my by e-mail today about a problem he encountered with DotNet interop: how to access a property of an object, if the property name matches a reserved word in NAV. A simplest example is from the Microsoft.Dynamics.Nav.SMTP.SmtpMessage class that comes bundled with NAV 2013.

Consider this piece of code:

Mail := Mail.SmtpMessage;
Mail.To := 'john.doe@noname.no';

If you try to compile this, it will fail. It’s simple: the To property name is invalid in the C/AL context, because it is a reserved word.

So, how do you fix it?

By |February 27th, 2014|Tips & Tricks|3 Comments|

.NET Tips & Tricks: Mediator Pattern (on steroids)

When I was writing my last post I had a distinct feeling that I was trampling over some boundaries of good NAV design. After all, you should not do stuff like that, NAV isn’t meant to do things like that, or at least that was how I felt.

And then two things happened.

First, I asked myself: what the heck, why not? What exactly is NAV meant to do, and why not things like that? If folks at Vedbæk didn’t provide an out-of-the-box solution for the problem, why should the problem stay unsolved?

Second, my dear friend and a fellow MVP, Hrvoje of Hudo’s Vibe, identified the thing as the mediator pattern. So, the thing I’ve done to NAV, civilized world has been doing to their programming environments for a long time.

And then I decided to take it all to a different level altogether, and expand the simple class which didn’t do much but raise events on itself when its method was called, into a full-scale framework. And here it is, the mediator pattern incarnated into a brand new Dispatcher class, adapted to NAV, and with features that make it truly flexible. I do not dare starting to think what are all the situations where you could put this thing to use in NAV.

Read on.

By |January 27th, 2014|NAV 2013, Tips & Tricks|5 Comments|

.NET Tips & Tricks: Dispatcher

There are situations when you want to exchange data between different objects in NAV, and there is no simple way to do it. One of those, that a friend stumbled upon a couple of days ago goes like this: you have a page which shows a subpage, that is linked to a factbox. Depending on the situation in the lines, you the factbox shows content from one table or another.

Your instincts may yell “ProviderID” at this moment, but there are some problems with it. ProviderID is used to set the link between different part controls on the same page. But if the link from the provider control results in no record being selected in the target part control, then the OnAfterGetRecord trigger in it does not fire, and you cannot update the content.

Another example may be this: depending on the line selected in the lines part, you may want to show either of two factboxes. Imagine – on a sales order, if you are on a line that sells a resource, you want to show the Resource factbox; and if you are on a line that sells an item, you want to show the Item factbox. You get the gist. There are not many ways you can achieve this.

As a matter of fact, when helping my colleague, I couldn’t think of any.

Except for an old trick which, unfortunately, does not work at all in the RTC. In the good old days of the Classic client, when heroes roamed the Earth, you could pass the CurrForm as a reference onto a function in a subform, which would then store the reference to the main form in its own Form variable. Then, when something happened in the lines, and you wanted to let the master page know, you called the function on the stored reference. It worked like charm. However, in NAV 2013 (and possibly 2009 – can’t bother to check) you cannot assign one page variable to another. Furthermore, the CurrPage variable has page ID in some funny range, and does not even correspond to the actual page number. All in all, no way you can pass, or retain, a reference to a page object, let alone the current page reference.

So, how do you have two, three, or more pages (or page parts, for that matter) talk to each other to pass some information when needed, in all those situations when ProviderID simply doesn’t get the job done (I could bore you to death listing those situations)?

.NET interoperability, what else.

By |January 23rd, 2014|Tips & Tricks|15 Comments|

Excel Interoperability Woes in NAV 2013

Handling Excel files in NAV 2013 (including R2) is not as easy as it seems at first. The Excel Buffer table – an obvious choice of the old days – supports only Open XML format (*.xlsx), and Excel Interoperability implementation seems a bit buggy (check the comments in my old post about .NET interoperability: http://vjeko.com/blog/the-beauty-and-the-beast-nav-and-net). You can still use automation, but then you must handle everything, or at least most of it, on the client end. And, to make it all just a bit worse, none of these approaches, even when they work, will impress you with their speed. All in all, if you want to handle legacy Excel files (*.xls) you will have to make some compromises.

Last week, Mark asked me for a bit of help on a project where he had to import *.xls files into NAV 2013, and he hit all of the possible walls provided by the Excel Buffer, .NET Interoperability components for Excel, and automation walls possible.

When I gave Mark my solution, he said: you should blog about this. So, here I am, blogging about a simple way to read data from Excel, any version, lightning fast.

By |December 24th, 2013|Development, NAV 2013|13 Comments|