"Namespace" reserved in VBA?

[riktek]

"Namespace" is reserved in VB.NET but is not documented as such in VBA, as far as I can tell.

VBA bucks a bit when I attempt a "Public Property Get Namespace()" but seems to take the bit after compiling, saving, and cycling the app a few times.

Lest I court disaster and before I go too far down the road with this, however, I thought I'd check here for thoughts about such usage. Thanks in advance.

 

[theDBguy]

I don't see it in the list of reserved words I looked at. Are you sure it wasn't just some sort of name conflict? Could it be the same name as some other property that you already have a reference to? Just thinking out loud.

 

[Pat Hartman]

Don't risk using that name. Change it now.

 

[MajP]

There will be no problem. NameSpace is a keyword in VB but has no meaning in VBA.
If there was a problem then VBA would have to worry about a lot of other VB Keywords that do not have any meaning in VBA.

Simple example. VBA has Implements and not Inherits as keywords.

So I can use Inherit without problem since there is no meaning in VBA. I cannot use implements since VBA does have this as a keyword. It will not compile.

VBA bucks a bit when I attempt a "Public Property Get Namespace()" but seems to take the bit after compiling, saving, and cycling the app a few times.

As @theDBguy suggested, this was unrelated. Code does not "kinda sort of compile".

The VBA list of Reserved words is more inclusive than just Keywords. It includes both Keywords and other words that could conflict with objects and be problematic if SQL. Not all are keywords. Keywords are part of the language and will not compile if used as a property, method, or variable name. You cannot name something For, next, loop, double, etc.

Pretty sure everything on that VB.net list of keywords would not compile if you name a variable using a keyword.
There are lots of access Reserved words that will compile and work without problem as variable, class method, or properties. I would not name a field, table, or control though.

"Reserved words" are words and symbols that have a specific meaning to Microsoft Access. If you use a reserved word or symbol to name a field in a desktop database or web app table, Access warns you that the word is reserved and that you might encounter errors when referring to the field.
You might also encounter errors if you use a reserved word to name a control, an object, or a variable."

So either it is going to compile or not. Since it compiled there is no problem.
Further, since it is a property of a class it is fully protected. For example I routinely have Custom classes in vba with properties like
Field, Recordset, Table, Name, Column, Row
and methods like
Requery, Sort, OrderBy
If it compiles (not a keyword) they are protected. It is not going to "sort of" conflict.

Don't risk using that name. Change it now

Just curious if this is based on something factual or just being extra cautious?

 

[The_Doc_Man]

My thought is whether riktek has added a library reference for which the word "namespace" is either a class, property, or method. In my ancestry database, which involves Excel and Word, when I do an "Object Browser" search for NameSpace, I get partial-word and complete-word hits.

For example, in the Excel library, class XMLSchema has a property called "Namespace" while Outlook's library has a call to LookupNamespace, GetNamespace, and AddNamespace. It also has a class called Namespace, which I presume is what you manipulate with the Lookup..., Add... and Get... calls. So the odd behavior might be some kind of reaction to something unexpectedly overlapping with a reference library. Particularly if there is a chance that Intellisense could be involved.

@riktek - do you have the Excel or Outlook libraries checked in the VBA >> Tools >> References list? Or some other place? If you have VBA modules anywhere, even in a form's class module, open the VBA window. (e.g. with Alt/F11). From the icon tool bar, find Object Browser. If in doubt, just move your mouse cursor over each icon long enough for it to pop up the tool tip help. When you open Object Browser, there are two text boxes. The top one selects libraries. You want the option "<All Libraries>". The second text box is blank. Type in "namespace" (without the quotes) and then click the binoculars (search) icon. You will see if you have a Namespace property, method, or class in your project.

 

[riktek]

I don't see it in the list of reserved words I looked at. Are you sure it wasn't just some sort of name conflict? Could it be the same name as some other property that you already have a reference to? Just thinking out loud.

Thanks, no, I didn't see it on the VBA list of reserved words, either, although it's definitely on the VB.NET list.

There isn't an express naming conflict in the app. The property is the first use of "Namespace" in the app, ever. Also, the project does compile, after all, and this ordinarily surfaces ambiguous names, in my experience.

I suppose the question, or one of the questions, is whether there is, or might be, an implicit naming conflict, i.e., with the underlying Access C++ code. I stumbled across a few undocumented keywords last week, actually, which dialed up my sensitivity a bit. STDIN, STDOUT, and STDERR, in case you're wondering. I should probably do a separate post about those.

By "bucking," I mean that after writing the property and its backing module-level string variable:

• Closing without compiling loops lengthily, requires Task Manager to close, then opens with the project irretrievably corrupted.
• Closing after compiling and saving similarly loops but on reopening the project is intact.
• Subsequent opens and closes go without a hitch.

It isn't clear, actually, whether I have a problem or may be courting one; that's actually the question. Perhaps just getting through compiling, saves, and cycling the app tells us things have settled down and that there isn't one. The behavior before getting to that point is unusual and a bit unnerving, however, and why I am proceeding with caution.

It doesn't sound as if there is a known problem using this name. Then, I suppose, the next question is whether any reason exists to think its usage might be risky. If not that we know of, then how might one exercise judgment in proceeding.

Again, thanks for the thoughts.

EDIT: This post didn't timely occur by reason of connectivity issues but was written immediately after @theDBguy 's initial response and before all others.

 

[riktek]

So either it is going to compile or not. Since it compiled there is no problem.

Pete, this was my initial take as well and thanks for confirming.

As noted in my prior response, which was written before yours but delayed in posting, the project does in fact compile and, after a bit of churn on closing, things settle down.

Further, since it is a property of a class it is fully protected.

Actually, it is a property of a standard module. I do this because this particular standard module defines application properties, including several object properties. As such, it should be a singleton; I don't want or need more than one instance, so doing this in a standard module prevents this conclusively. Also, being a standard module, it loads in its entirety on first reference (which occurs on startup), so I don't need to concern myself with predeclaration or instantiation. The properties self-heal (via static local or private module-level variables), so it's quite robust. Application events are another matter, however, and belong in a class so they can be sunk via class instances assigned to remote variables declared WithEvents.

@riktek - do you have the Excel or Outlook libraries checked in the VBA >> Tools >> References list? Or some other place?

No, none of these references exist in the project in question. I also double-checked by doing a search in the object browser and nothing turned up.

I should hasten to add, as noted in my prior post, that I don't actually know whether this usage poses or courts a difficulty; that's actually the question. @MajP thinks not, for important and valid reasons. This said, usage in other referenced libraries is important, as I learned recently with respect to STDIN, STDOUT, and STDERR. But, as noted, this isn't the case here.

Really, having ruled out express name conflicts, I suppose the question is whether any risk exists of an implicit naming conflict, i.e., with the underlying Access C++ code. @MajP seems to think not and I'm inclined to agree.