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.
Upgrade projects are lots of fun. They are full of challenges that keep you busy day and night all the time.
I have encountered a very interesting challenge on my last upgrade project. The object upgrade process was completed, the data upgrade procedure ready to go, but when we started first tests we realized that the data upgrade execution takes some 39 hours to complete just Step 1. Without even bothering to measure Step 2, we realized we need to do something about it. The customer is running a 24/7 business, and cannot accommodate for such a large downtime, just to upgrade data from NAV 2009 R2 to NAV 2013 R2.
Eventually, we got it down to under a second. If you want to learn how, read on.
Thanks to everybody who attended my session at Directions US in San Diego today. It was a pleasure to deliver it, and I hope you enjoyed it as much as I did. It surely would have been much better if I were not running some kind of a flu, but I won’t complain.
As promised, I am making all the content from the presentation available for download from my blog, so please feel free to download any of it, and (ab)use it in your real-life projects.
Did you ever need to identify the current object type and ID, programmatically, from within the object? For example, detecting the current table ID in a table trigger like this guy? Or current codeunit ID from inside the codeunit?
Why would you need something like this? If you are inside a trigger in, say, table 18, you do know that you are in the table 18, and you can refer to it as 18 or DATABASE::Customer, right? Yes, but this is hardcoding. If you move this code to a different table you’d have to change the hardcoded constant to whatever that other table is.
Microsoft was well aware of the need to know the currently running object ID in some cases, because there is the OBJECTID function to the CurrPage and CurrReport built-in objects. However, for tables, codeunits, XMLports, and queries, there is nothing of the sort.
Now, using .NET Interop, you can easily (well, easy is relative) get this info.
Indexed properties are commonly used in C# because they allow a lot of syntactical flexibility, and make the code more readable, and easier to follow. Indexed properties are very similar to C/AL array indexing, except for two important differences:
These two examples show these differences:
