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…
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.
GETLASTERROROBJECT vs. GETLASTERRORCODE
Good. At this point we know everything about exception types, what they are, how to obtain them, how to compare them (at least directly). All of these have suddenly become relevant now that we have GETLASTERROROBJECT function in NAV 2015.
But an old friend is still around, the GETLASTERRORCODE function, what about it? Why do we need to bother with GETLASTERROROBJECT when we have a simpler approach, with less peeking into inner exceptions, less reflection, less spooky, obscure .NET internals?
Upgrade Codeunits in NAV 2015
Once upon a time, and really not such a long time ago, there was no such thing as a codenit type. In all honesty, there is still no such thing as a codeunit type – there is subtype, though. (Why we have subtypes, without having types, beats me, but let’s let the semantics go.)
Nowadays, we have four codeunit types. NAV 2009 SP1 brought along the Test and Test Runner types, which – in my experience, at least – haven’t seen much runtime (which is a pity, if you ask me). And now NAV 2015 brings along another type: the Upgrade codeunit type. The mere sound of it makes my heart thrill. The Upgrade codeunit. Mmm.
Synchronizing Database Schema in NAV 2015
Before NAV 2013 R2 the “database schema synchronization” was an unknown term. Either you could do a database schema change, or you couldn’t. There was no such thing as data loss. If you wanted to change a field type or delete a field (or delete the whole table for that matter), and there was data in that field in the table, you got an error. Data present – no go.
However, with multi-tenancy, and the possibility to mount tenant databases originating from different applications, suddenly there was an issue – how should NAV handle possible differences in database schema for different tenants? Should we force the change at the cost of data loss? And thus the term “database schema synchronization” entered the vocabulary of regular NAV Joes.