One of major limitations of control add-ins is not being able to define HTML. It seems so unbelievably unbelievable, that anyone looking at it from the outside of the NAV/BC playground may say “obviously, you must be missing something!”. But I am not. The one thing that you would expect to find first when defining a control add-in (and control add-ins in NAV/BC are nothing more than pieces of HTML that live within the allocated area of your browser real estate) is to be able to define the HTML. And yet, you can’t define it. The only way to show any UI from your control add-in is to procedurally create any of your control add-in HTML.
Whoa! This has been quite an event, the Directions EMEA 2016 in Prague. There has never been this many people (1.700+) and it was quite a pleasure connecting again with old friends, and meeting new friends. Also, it has been quite a pleasure listening to many good sessions, and an even bigger pleasure delivering four of them.
And this is why I am blogging now – to follow up on my promise during my Polymorphic Event Patterns for C/AL. I promised you that I’d post my pattern proposal online, and here I am doing it.
There are situations when you’ll want to call Web services from C/AL, and those Web services might be protected by certificate that your local machine cannot validate directly. Web service might be secured with a self-signed certificate, or by a certificate obtained from an authority that is not globally trusted.
A friend of mine had this specific problem today, so I remembered that a short while ago I made a “how do I” video on this specific topic. Thanks, Mathias, for giving me a prod, and reminding me of a quick blog topic.
Another problem with C/AL DateTime is that C/AL is a bit rude when it comes to System.DateTime: whenever C/AL compiler (or runtime) encounters a value of System.DateTime it’s automatically converted to C/AL DateTime.
When you combine those two problems, you get the following problem: even though System.DateTime is perfectly capable of handling time in both UTC or local kind, C/AL isn’t.
To prove this point, just run this:
MESSAGE(‘Current local time: %1\Current UTC time: %2’,SystemDateTime.Now,SystemDateTime.UtcNow);
It will show this:
And I am currently sitting in a UTC+1 time zone, mind you.