I love unsolvable problems. I simply do. I had one a few days ago in the office, and I solved it.

So, the problem went like this. A discussion has been raised among developers about whether it would be possible to display a blank form over a populated table, where user would be able to immediately enter the data of a new record, without having to press F3 (or inserting a new record manually). The problem is, this doesn’t work that way in Dynamics NAV.

I started this blog too seriously. Instead of starting relaxed, I jumped right into the battle head first, with difficult topics such as convergence and history of Dynamics. When I was thinking about starting this blog, one of the ideas was to discuss mainly technology and functionality. Last time I wrote about technology and functionality I wrote a disertation. This time, I’ll be quick.

Hello there! I could as well start with “Hello there, myself!”, but that’s a charm of blogging – you do it regardless of whether there is anyone else reading this stuff. I’ve read somewhere that most blogs have exactly one regular reader – the blogger himself. So far, this is the situation with my blog, and I don’t really mind if it stays that way for the time being.

Ok, I’ll get to the point. There is a change in my career path on the horizon. Nothing really radical, because I am staying in the same business, I am continuing to work with the Microsoft Dynamics NAV, but my work might be a little bit different. To be totally honest, this was on the horizon for quite a while, but there have been some, err, circumstances, and I wasn’t really sure whether it will be go, or no go. Now it is 99% go, but yet I don’t feel comfortable to blurt it out all at once. Suspense is the key…

Tons of documents exist about Microsoft Dynamics NAV, but most of them start with marketing lingo, and don’t wander away too much from it altogether. While it is nice to know that it is a system which will give you freedom to focus on your business, it is also nice to know what is it made of, and how it works inside. Inspired by a total lack of resources which would give a clear picture of all the system components and their relationships, I wrote this post in hope someone might find it helpful.

It has been a while since I was here, and I will not try to make any excuses. I could say that I have been busy (which would be true), and that I have a family that I love spending my time with (which would also be true), but true reason is the one you all know: I have been lazy.

Last time I promised to say a word or two about convergence once. Let me do it this once.

Posts navigation

When comparing .NET variables, including Enums, you cannot use C/AL comparison operators. To compare .NET variables, you must use the Equals method (of the System.Object type) that all .NET types implement or inherit. So, instead of IF var1 = var2, or IF var1 = var1.EnumValue (in case of an Enum), just write IF var1.Equals(var2), or IF var1.Equals(var1.EnumValue).

I see this mistake often being made or attempted by developers, even though it has been documented inside .NET Interoperability documentation since it was introduced with 2009 R2.

Make sure that you don’t access the Microsoft.Dynamics.NAV JavaScript object before the document ready event fires. If you do so, you might experience problems on Chrome when the user refreshes the browser (F5). It appears that on refresh Chrome loads (and runs) scripts in different order, and depending on how complex scripts included in your project are, your code might get executed before Microsoft’s script is loaded, and it will cause nasty script errors. This occurs only on Chrome on PC.

When you have to format C/AL variables (numbers, dates/times, booleans) for exchange with other apps, call FORMAT(variable,0,9) instead of simply FORMAT(variable). The format 9 formats the variable according to XML standards, and this value can then be interpreted correctly on any system with any regional settings. This is useful also when passing string-formatted values from C/AL to C# or JavaScript.

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. This was changed in NAV 2009, so ever since that version you can check HASVALUE before you decide to call CALCFIELDS first. It makes all the sense – you don’t need to pull up to 2GB of data over just to see if anything is inside.

If you are an old-school guy (or just old, as me), and you CALCFIELDS first, HASVALUE next, maybe it’s time for you to reconsider it.

Rembember – the pattern is: IF Field.HASVALUE THEN Rec.CALCFIELDS(Field);