Protected Variables

“Protected Variables” might not be a familiar topic in the Business Central world. It was at least not that familiar to me ;-). So I wanted to make a small post to make this more known in the community, so that at least you are aware that it exists .. and it might give you some more extensibility options that you might not have considered.. .

The concept is simple: protected variables are variables that you can access from a dependent extension. So .. thinking about this .. it actually has only any effect on extension object, because that way, you’re kind of “in” the object. So, we’re only talking about extension-objects being “table extensions”, “page extensions” and “report extensions”. I’d normally say that you can find more information on Microsoft Docs: Protected Variables – Business Central, but quite honestly, there’s not *that* much information on there.. .

Now, you might know I’m not particularly fan of “global variables” as such, and a protected variable, is actually a global variable, that you extend outside the scope of the extension .. so as such, you make it even more global than it would be as a normal global var 😳 (one might wonder what is “protected” about a var that’s being made available to the outside .. 🤔). However, I do think that these protected variables open up some extensibility-possibilities in some scenarios. Especially pages and reports. For tables, I would really doubt that when I’d need access to such a variable, that the best design for that particular feature would have been implemented.. .

How does it work?

Well, I created my own example which you can find here on GitHub: waldo1001/blog.ProtectedVariables. It has a MainApp, and a Dep(endant)App. And you can see that in the objects, I declared a normal var, and a protected one, like this:

Now, in an extension object from the DepApp, you can actually access (and change the value of) that variable, like:

While you’ll see when I’d try to use the “NormalVar” in the extension object, it’ll simply fail by mentioning that the protection level is wrong.. .

Typical Usages

When you browse through the BaseApp, you find about 264 occasions where Microsoft has declared protected variables. Obviously in the objects that are extendable. At least “mostly”. There are some codeunits with protected variables as well – which I have no idea why that is. Afaik, that totally doesn’t serve any need. If you have a clue – please put it down in the comments 😉.

Anyway, from a short analysis for browsing through these protected variables, you can clearly see some typical usages, like:

• Visibility of Dimension Values on pages
• HideValidationDialog on document tables and reports (and even codeunits .. which I still don’t understand 🤷‍♂️)
• About all the statistics-values on statistics pages

Then, there are also a bunch of other places … which one might wonder .. why those, and not others? Like here you see a bunch of normal variables, and then a bunch of protected ones:

Well, thing is, people have been requesting numerous variables to become “protected” to serve their extension. Just look at these issues on Microsoft’s GitHub for example.

So, keep in mind this is also an option for you: if you need access to table/page/report-variables from the base app, just file your own issue, and Microsoft will respond fairly quickly.
And if you’re an ISV, you can foresee (and should think about) your own protected variables if that would make sense for your app ;-).

Open Questions

While writing this post, I did come across some odd things as well. Like the already mentioned protected vars on codeunits which I don’t have a clue for what they are there for.

But the same for protected procedures (which is not *really* the content of this post).

Well, any of those (protected vars or protected procs) in a codeunit, I have no idea why that would be useful. It doesn’t do anything really expected:

• a protected proc in a codeunit seems to act like a local proc
• a protected var in a codeunit seems to act like a global var

E.g. if I would have a codeunit like this in a main app:

Then, in a dependent app, I wouldn’t be able to do much with these protected stuff.. . I mean: in case of a subscriber, I can simply access both the protected var as the normal global var. And in case of the procedures, I’d not even be able to run the protected proc, while I would be able to access the global procedure, which is obvious and expected.

So, I have to conclude that the “protected” keyword anywhere other than in an extensible object (i.e. page, table or report) does not make sense and may be is something that simply shouldn’t be available in the language.. .

If anyone can comment on this, or have any more insight – you’re more than welcome to comment below ;-). Here is a twitter-thread about the same topic as well:

#bcalhelp me out here … I stumbled on this protected variable in a codeunit in de baseapp (codeunit 333 "Req. Wksh.-Make Order").

Why would I ever create a protected var in a codeunit? It's not that I can access it from an extension, right? Can I though ..? 🤔 #confused pic.twitter.com/ktTtWhnDnF

— waldo (@waldo1001) August 25, 2021