Business Central Development

First of all, thank you all who attended my session today. It was a lot of people in the room, and with the competition from Microsoft talking about a very hot topic in the other, bigger room, I really wouldn’t expect to see all of you there.

And yes, I almost forgot… Somebody (sorry, I didn’t catch the name) asked me to put my life hack on the blog as well, so here it is. For all of you who were not there, I use this as a template for declaring .NET variables – until Microsoft provides means to declare them in a simpler ways. Inline, anyone?

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 deliver them here with no explanations or comments – when Luc publishes the sessions and the slide decks on Mibuso, you’ll be able to figure out what’s what.

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.

To check if a BLOB field has a value, you call its HASVALUE function. For example: IF Item.Picture.HASVALUE THEN; In older versions, earlier than NAV 2009, you had to call CALCFIELDS before you could check HASVALUE, which – if you think of it, did not make much sense.

Any function that accepts only one parameter can be called as if it were a property, and this applies to built-in system functions, your own custom functions, and even .NET methods alike. Instead of doing it like Report50001.SetDefaultPostingDate(101015D) you can always do it like Report50001.SetDefaultPostingDate := 101015D.

While it may be a cold day in hell before we see any TRY..CATCH constructs in pure C/AL, we are all far more lucky when it comes to .NET interoperability. In this blog post I’ll (re)present the same concept I demonstrated during NAV TechDays 2013 last year in Antwerp, because I am quite sure this nifty little trick got lost under piles of other posts on this blog.

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.

If you want to rollback the database changes, but do not want the code execution to end, simply call ASSERTERROR ERROR(”); The ERROR(”) will quietly rollback the data changes, and the ASSERTERROR will capture the error, allowing the code execution to continue.

Did I CATCH your attention yet? At least I did TRY. Now that I have completed my series on exception handling in C/AL , a very valid question pops up: why don’t we have try..catch syntactical constructs in C/AL, the way we have it in other programming languages?