Why you should care about the name of C/AL controls, actions and entities?

Having worked for a while now with Visual Studio Code and AL, I have made a number of page extensions, where I really wanted to say something bad, to who every decided it was ok to name something Control1, Control2 etc!

How exactly do you know which control to use when they are named like this:

Luckily, they are not all as bad as the sales invoice page but would say that especially this page would have been great if they had been named a bit more carefully back in the days. At least to me, then this is one of the most commonly customized pages.

I’m sure I’m really not going to say something bad to who ever came up with having control names, but just use them as numbers. I don’t think that anyone really cared about it, when pages where introduced with NAV 2009. As I don’t think anyone had anticipated where those control names ended.  But at least whoever is responsible should buy us all a beer at the next NAV Tech Days.

How can you find out what is behind the names?

The easiest is just to select one of the controls. Then use the Go To Definition:

That will open a simplified version of the AL version of the Sales Invoice page. Enough for you to able to use Ctrl+F to find the control. The “Go To Definition” only brings you to the object, not the actual control.

In this case it shows that most of the controls with “ControlXX” names are fact boxes, and ship-to sub groups.

The information about which were fact boxes, would also have been available without opening the page object. When you scroll the list of options with intellisense, then it shows you the context of the control, which here is helpful. Most other places it just shows a group.

But most places it just shows the control name and that it is a group.

What should Microsoft do about it?

About the sales invoice page? Nothing in C/AL. It is too late, changing it now may break many of the extensions already out there. We just have to live with is for now.

I only hope that they would “fix” the “Go To Definition”, so that it would go directly to the control in question. Or also show the group hierarchy in the preview.

Of course, they should also make sure to name all new objects, both C/AL and AL, with care so that they are understandable and easy to use when extending to them.

But that is not different from what everybody else should do.

Name all you controls, variables, fields, report datasets and columns, well everything in your code with a "name", so that the next developer doesn’t have to guess what may be natural to you.

Comment List
Anonymous
  • Eric,

    I do not think it's too late too change this in C/AL. We're still on development preview versions of C/AL and Microsoft could very well change this, to make sure we are better prepared for future. There is actually an open issue regarding this on github: https://github.com/Microsoft/AL/issues/527, I suggest you voice your opinion on changing the standard control names there.

    Sure, it would break quite a few things for existing extensions, but MS could provide an intermediate tool to handle that (i.e. replacing references for existing controls) and it would be much nicer going down the line, when the newcomers wouldn't need to wonder "why the hell to I need to add my field after "Control0014801982", and not "CtrGroupGeneral"?.

  • Thanx for posting this, Erik. Had it on my list to do to, but glad you did while I did forget about it. ;-)

Related
Recommended