DEmos from the .NET Interop for Mere Mortals
Thanks to everybody who attended my session today at NAV TechDays 2014 in Antwerp. As promised, here are the goodies from the session. I’ve simply taken the objects and I…
NAV TechDays 2014 Pre-conference goodies
So, NAV TechDays 2014 have started, again, with the pre-conference sessions that were all sold out and packed full.
Today I had an extraordinary pleasure to teach the advanced .NET Interoperability concepts to 15 people that came from all over the world, from Brazil to Australia. It was an interesting workshop, challenging – I must say (thanks to Rafael who made me improvise a solution to a typical DotNet limitation), and I am looking forward to delivering two more sessions about .NET and Control Add-ins tomorrow, and on Friday.
As promised, I am making the materials from the presentation available for the download, in case you want to learn the same stuff the attendees learned today.
Adding a ControlAddInReady event to custom controls
When interacting with custom controls on your pages from C/AL, you must be absolutely sure that the control has been instantiated. If it is not, you’ll get an error such as this:
The reason why this happens is that C/AL code gets to execute before the page has been rendered, and thus also before the custom controls have been instantiated.
NavUserAccountHelper class
Even though my blog queue has a lot of far more interesting todo entries waiting for their prime time, on my short flight to the Directions EMEA conference in Poznań, instead of dozing away or blank-staring through the window, I’ve decided to introduce the Microsoft.Dynamics.Nav.NavUserAccount.NavUserAccountHelper class, a part of the built-in .NET stack of Microsoft Dynamics NAV since the version 2013 R2. My friend, Eric, asked me to blog about it, so here it is, this post is for you, Eric.
Three Whys about .NET Interoperability
Once upon a time, a smart bloke named Saikichi Toyoda came up with a 5 Whys troubleshooting technique. It postulates that you only need to ask “why” five times to get to the root cause of any problem in a cause-and-effect sequence.
However, with .NET Interoperability in Microsoft Dynamics NAV (pick your version here), I’ve only had to ask “why” three times today, and unfortunately I could not get to the root cause, except – poor design decisions.
It all has to do with a simple .NET class: System.DBNull. The first “why” is simple: why is there no support for fields on .NET types. The second “why” is even simpler: why don’t we have a null constant in C/AL. And the last “why” downright falls into the “what the heck” category: why did somebody think it was a smart idea to replace DBNull value with null.