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.
One more great Directions EMEA event is over, and it was a great experience again. I am a bit sorry, though, that my main focus was delivering presentations, so I enjoyed myself less mingling around, meeting new folks and consuming content. But it was still a great event.
What I liked a lot is the audience participation and the interest – all sessions, at least those that I attended or delivered, were packed full. It was a real pleasure presenting and demoing tips and tricks in my “Spicing up your user interface” session, and ranting about barriers and gaps between consultants and developers in my “Breaking the barriers” session. Thank you all who attended and I hope it was worth your time.
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.
My two last blog posts tackled two aspects of working with control add-ins: making any property or method accessible to C/AL, and making any event accessible to C/AL The first was a simple trick, the second was a bit more complex. Together, these two tricks enable you to easily interact with whatever Windows Forms control the add-in shows: you can access any of inner control’s members – properties, methods, or events. At this stage, there is a very simple, but robust framework in place, which lets you publish any kind of control and make it fully available to C/AL. Cool.
But, couldn’t we make it a bit cooler? How about being able to instantiate any control, and having C/AL decide which control to instantiate, instead of hardcoding it in the C# code?
Yes, we can do this.
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.