I stand corrected. A month ago I wrote about how to pass JSON from JavaScript to C/AL and then handle it inside, and what I wrote is not wrong, but I just figured a simpler way.
Too bad all this is not documented, but hey – that’s why blogging is fun.
Yesterday, I said I was closing this year of blogging, but I wasn’t really. Closing a year with 39 posts, and leaving a question lingering, wouldn’t be too fair, would it? If you read my last postabout how to pass objects from C/AL to JavaScript, you must have wondered if it’s possible to also pass objects from JavaScript back to C/AL.
Wonder no more. It is. And here’s how.
Many cool things often go undocumented. I’ve just stumbled upon one of those, and it comes in handy to close this year of blogging.
Imagine this situation: you have a server-side .NET object, that you want to pass on to the client. With the .NET System.Windows.Forms-based objects, you have to make the object serializable, deploy the object to the client-side Add-in folder, and then set the RunOnClient property on the C/AL variable to Yes.
However, if the client is not .NET-based, if it is a cross-client JavaScript-based one. You may think that it’s not possible to pass the custom object on to JavaScript code. And you may be wrong.
Most of What’s New information about NAV 2015 will mostly talk about the Word report layouts, as well as the C/AL support for these. However, most of the What’s New documentation doesn’t have a single word about what I find among the most exciting new reporting features in C/AL: the capability to programmatically control the request pages.
Fasten your seatbelts, you are in for the next round of Web Reference vs. Service Reference, which brings an unexpected twist to the story. After giving reasons why not to use Web References, I’ll now put my devil’s advocate’s hat on, and try to have you change your mind.
It’s simple: there are situations where Service Reference won’t work as expected, and Web Service will.