Json is a common data format, but in NAV it’s support isn’t huge. Especially when it comes to parsing Json. Of course one can use Newtonsoft dll, wrap it in c/side code and parse the contents. Still a bit too complex and not very straightforward.
But what if we just deserialize or serialize Json to XML and XML to Json? XML support in NAV is good, and anyone know how to handle it using xmlports or .Net XmlDomDocument. Second is preferable as xpath is way more flexible than xmlports.
Honestly, the code below isn’t mine, I’ve googled it an all credits goes to Ponç J. Llaneras .
This is very useful bit of code indeed.
The only issue I have with this – is the fact that this one will not work in extensions until MS add .Net support to extensions if this will ever happens. We still need an external dll too.
Just wondering if anyone built a json parser in pure C/AL? Or maybe MS will just include it into future NAV?
Well, I thought RDLC reports will go at some point, but even for NAV 2018 they are still here. Apparently they may survive longer than I will.
There is one particular thing about RDLC reports I always hated. It is the method how do you send data to header. This horrible getdata/setdata functions. The main problem with them is that data can only be accessed by index number. Like that
I always hated this meaningless getdata indexes. To get what do they mean – it is a nightmare, especially if one is not report author. Even on my own reports after day or two I got no idea what this index mean and to what dataset filed it actually refer. Let alone the fact that they all displayed as ‘ “Exp” ‘ in designer.
I can’t help with second, it is a question to VS team, but I think I can help with first.
Imagine one can refer to a dataset item from header by dataset item name, like that
That would save hours and hours both on report design and on any rework.
Actually, this is fairy simple to achieve. I am sort of surprised MS haven’t done this since 2009, nearly 10 years! Considering MS probably started development of RDLC reports for NAV prior to 2009, 10 years mark is well passed.
So let’s list the contras of standard getdata/setdata:
On setdata expression the order of fields does matter. Add something to beginning of expression or in the middle – and that’s it – everything screwed.
On getdata the index reference is 100% meaningless, one have to refer back to setdata to figure out to what filed the index refer every time.
Then let’s see the pros of new approach:
on setdata function the order of fields does not matter anymore. Need to add a field – add it on first line, with zero scrolling.
On getdata – forget the horrible indexes, just refer your field by a dataset item name as string.
Sounds good?
So then let’s lee how this can be achieved.
RDLC reports code is just VB script, nothing more. Despite I am not expert of VB by any means I managed to create a new getdata function, see below:
I know this code is ugly and untidy, I already see how this can be improved, but I can’t be bothered. It does the job after all.
So this is our new getdata, not much more complex than MS one, isn’t it?
What about setdata then?
And expression itself…
I think expression above don’t need to be explained per se, if one ever done a RDLC report… Obviously everything need to be converted to string on this setdata expression, if you deal with a bitmap (or other binary, but what binary apart of bitmap we may have on report?) – use Convert, if anything else – just do CSTR.
That’s pretty much it. Yes, I t is a tad bit more complex, comparing to standard setdata. But so much easier to use after all.
If you like this – use this. If there is anyone from MS NAV department – feel free to take this, re-do to MS standards and use for new versions of NAV – there is no copyright, I am happy to donate this little bit to MS…
With all roughness of functions above I do believe they are better that what we had to deal with for last 10 years.