Into the Wilderness: Text Constants and Mysteries of NAV Development
One of the curiosities about developing in Microsoft Dynamics NAV (Navision) is that things are generally done a certain way, and you don’t always know why. These are the traditions of NAV development, and their origins are shrouded in mystery.
For example, I had always wondered why text constants were named “Text001,” “Text002,” etc., instead of having more logical names that referred to the content of the text constants in question. I worked up the courage to ask around internally about this the other day, and we had quite the animated discussion. Thankfully, nothing escalated to the point where we had to settle our issues in Thunderdome, but there were some different points of view. (It also helps that we have some staff members who have been working with NAV forever; some of them even worked for Navision before it was purchased by Microsoft.)
According to tribal lore, the naming conventions for text constants arose from handling multi-language implementations. If I call a text constant, “TextErrorForZeroInventory,” that makes sense to someone who speaks English, but developers who speak a different language (or who have English as a tertiary language) might not know quite what it means. And if you’re developing a product that’s translated into dozens of different languages for users and developers all over the world, that’s a problem. So, the original NAV development team got into the habit of using text constant names like “Text001,” and then everyone just had to look to see what it said if they needed it. (And sometimes, you copy/paste it into a comment if you’re building a string to display with a lot of embedded variables.)
While that practice makes really good sense if you’re trying to write an ERP system for everyone everywhere that will be used for years (in some cases, decades) to come, I think it makes a little bit less sense if I’m just doing a change for a single end-user. While my brilliant coding skills have come up with some things that were certainly a great idea for everyone everywhere to implement, most of the changes I make are specific to a single end-user, and generally that end-user is only using a single language. (Come to think of it, I don’t think I’ve ever needed to do a multi-language NAV install. But I’ve also never gotten to work with a big, multi-country international NAV rollout that had a lot of different countries covered in a single NAV database. Or maybe I’ve never had to work with a big, multi-country international NAV rollout. The difference between getting to do something and having to do something can be tricky to parse out if you haven’t done the something in question before.)
So when I’m doing modifications for a single end-user, I try to give my text constants names that reflect what they actually say, along with appending the characters “AP_” to the front. An error about zero inventory being on hand would be named something like “AP_ZeroInventoryError.” If I did need to do a multi-language implementation, I’d follow along with the standards for custom object names and start with “Text50000,” then “Text50001,” “Text 50002,” and so on. Apparently, this is the official way of naming text constants, and I have noticed that add-on writers tend to stick with naming their text constants “Text” and then a number that reflects their custom object numbering range.
And finally, I am totally excited that Street Fighter V was recently announced. I’ll probably have to pick up a PlayStation 4 just to play it. (Investing in a nicer PC for gaming wouldn’t be a bad idea, either. It wouldn’t be the first extraneous purchase I’ve made for a crazy obsession; I bought three copies of Ultra Street Fighter IV, and I have more joysticks than I’d like to admit.)
If you have any further questions about this or other development questions, please contact one of our development experts at ArcherPoint. If you liked this, you might like to read more of Tom Hunt’s blogs, or check out our collection of Development Blogs.