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.
When importing files using XMLports, and especially when handling text files, file encoding is important. If the XMLport expects ASCII, and you feed it UTF-8, you may get scrambled data. If you have mismatching unicode input files, it may just fail altogether. Therefore, making sure that encoding is correct before you actually start gobbling input files might be important.
At least it was for me. I am currently automating data migration for a major go-live, and I am feeding some 30 input files to NAV, and I want to make sure they are all encoded correctly before I enter a process which would take another geological era to complete.
Detecting encoding is not something that pure C/AL can help you with, so I naturally went the .NET way. My position is that there is nothing a computer can do that .NET cannot. My another position is that there is no problem that I have that nobody before me ever had. Combining these two, we reach a yet another position of mine, that there is nothing that computer can do, of which there is no C# example, and typically I look for those on http://stackoverflow.com/
So, here’s the solution.
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:
So, it worked. I found just enough spare time to try out the crazy idea I mentioned in the last post. It’s about control add-ins and events. In the last post I gave a tip about exposing the actual control as a property decorated with ApplicationVisible, which allowed you to directly access all properties and methods of the control.
However, if you wanted to do the same with the events, you had no other option but to manually create an event handler for each event type, then to add an event handler for the actual event from the original control, and finally to raise the event on your control add-in from the event handler for the actual control. You lost me already, so did I 
This is what I am talking about. Imagine a button, and that you want to allow NAV to respond to its Click event. This is what you need to do:
Might not seem too much, but consider that you must do this for every single event that you want to use, that it requires some rewrite-restart-redeploy-redesign-rebind workout to implement support for another event you forgot last time, and then it becomes an problem. Probably the ugliest part of it all is the fact that for C/SIDE to properly insert the new event triggers for an updated class, you have to unbind the Control Add-in, and then to re-bind it. This loses any C/AL code in previously existing triggers. Add to the equation the human error variable, which kind of readily pops up whenever manual code duplication is involved, and you’ll have a lot of happy hours fixing the mess and juggling dlls and C/AL code back and forth.
How about this. How about not having to add anything at all to your C# source code, and not having to redeploy anything, and then to support any event you want just through a single line of C/AL code?
Yes. That’s what this blog post is about.
.NET Framework is full of programming conceptual gems, that are now at the fingertips of us poor C/AL folks. One of those is generics. However, the C/AL support for generics at the first glance seems rather limited, and the help file says that you can’t specify data types, and that all generics will be instantiated with System.Object as their type. However, with Microsoft Dynamics NAV 2013, there is a very simple way which allows you to use generics with other data types, as well. So, if .NET Framework Interoperability interests you a slightest bit, here’s a solution. The example below will be for the System.Collections.Generic.Dictionary<,>, and I will show how to use instances of the Dictionary<,> object with any desired data type, without having to pull in any external assemblies. (more…)