Long time no see, but that’s how it gets every now and then, I guess… Anyway, I am still alive, still kicking, just don’t get to blog as much as I’d hope for, it’s work, and life and universe and everything.
So, I am back with not a typical “Vjeko” post, just a simple AL opinion piece. A tip, without a trick.
One of the problems we’ve all suffered from in the old days of C/AL (who remembers that still, anyway) was inability to define real text constants. One thing we all avoided was using hardcoded Text literals, like this:
It was not only about the sheer scariness of using Text literals in C/AL, stuff that if left unchecked could cause process issues, something nobody in the ERP world (especially those on the business end of it) likes. Arguably, the worst thing about this kind of code was total lack of reusability. If you had to reuse the literal, you would have to write it again:
Yeah, the mismatch (or typo, whatever you prefer) is intentional to prove my point. You could mistype it, or somebody may decide to change it and then forget to change it in all places, or… stuff happens, you know. It was no good.
There were no constants, and it sucked.
Yeah, yeah, there *were* TextConst constants, but that’s not it. The moment you did this:
… somebody could come in and “fix” it like this:
And there was no way for you to prevent them. There goes your discoverable extension, things break up and your users start yelling your way.
Back in those pre-historic days, I’ve seen people work around this problem like this:
The “constant” is coded in one place, other place call the wrapper function, and world goes on. That was the way to do it in C/AL, truly.
Fast forward back to present. I’ve got myself in the middle of refactoring a chunk of code migrated from C/AL to AL a while ago. It’s full of “pluggable” things that identify themselves to various discoverers, and it’s full of “constants” coded with this function-that-returns-a-hardcoded-literal pattern.
While this worked miracles in C/AL, in AL we actually have a far better way to handle this. Labels. Yeah, fells like I am discovering hot water or sliced bread or something, but please, for the record, don’t do this:
Instead, do this:
If you set the Locked property to true, you are making sure nobody inadvertently translates it, and you keep it a bit cleaner. This is especially true if you have multiple constants – listing them in your var block will be much cleaner than creating a function a piece.
Here endeth the lesson. No rocket science, just an easy one to document my train of thoughts for posterity. Everyone is entitled to my opinion, after all 😁
Pingback: Tip: Text constants in AL - Vjeko.com - Dynamics 365 Business Central/NAV User Group - Dynamics User Group
Thanks for sharing.
May I know why you prefer to use label instead of textconst ENU=”Something “?
Please tell me you are not serious? 😮
Ooops, just declared an GetId function yesterday 😁. To my defense I had the tought “In the future this is going to be a part of a setup table and then I only have one place to change. Put I get your point. More easily to find all these “hardcoded values” (constants) at one place
You had the “same” locked property in C/AL for text constants too! Look for the ‘***’ preview token text contant in CU80 for example.
I think what truly helps is the better readability of the AL code and of course handling the translations outside of the source code. If we had the opportunity to write translations where we define the labels a lot of us would never touch the xlf files!
If you are referring to
FakeDocNoTxt, then I can see it’s declared asFakeDocNoTxt@1071 : TextConst 'ENU=***';– how is it locked?“And there was no way for you to prevent them”.
I always use: Language=”@@@”, Value = “{Locked}”
Seems to be the way Microsoft does this in the standard C/AL code…
I was not aware of this – honestly. But looking at some code examples, it’s not exactly the same thing, is it? What I can see, for example in CU80, is that all of @@@ constants have also the ENU version.
No. It is not “preventing” it, so probably not the exact same thing.
I believe @@@ means a comment (sometimes the use it to explain the contents that %1, %2 etc. will be filled with), and it was probably agreed with the Microsoft translators that a comment with “{Locked}” means “Keep your hands off this” or something like that :-).
So no, not the exact samt thing, but sort of solving the same issue :-).