Hello,

I’m just wondering if anyone else has come across this Enum “quirk”.
Tested on XL2003 & 2010.

Option Explicit

Public Enum List1
nam1 = 11
nam2 = 22
End Enum

Public Enum List2
nam1 = 11
nam3 = 33
End Enum

Scenario 1:
Sub Test ()
Debug.Print nam1
End Sub
Do a compile. I was expecting a “Compile error: Variable not defined”
message, but got “Compile error: Ambiguous name detected: nam1”
message instead.

Scenario 2:
Sub Test()
Debug.Print nam3
End Sub

This did NOT generate a compile error, but printed “33” when executed.

Scenario 3:
Sub Test()
Dim nam3 As Long
nam3 = 99
Debug.Print nam3
End Sub

Of course, this one compiled without error and printed “99” on
execution.

In the past I’ve depended on the compiler to pick up missed
declarations, but it seems this can’t be relied on when Enums are
involved.

Any comments appreciated.

Regards,

Dave U

On Wed, 13 Apr 2011 12:32:00 -0700 (PDT), Dave Unger wrote:

Hello,

I’m just wondering if anyone else has come across this Enum “quirk”.
Tested on XL2003 & 2010.

Option Explicit

Public Enum List1
nam1 = 11
nam2 = 22
End Enum

Public Enum List2
nam1 = 11
nam3 = 33
End Enum

Scenario 1:
Sub Test ()
Debug.Print nam1
End Sub
Do a compile. I was expecting a “Compile error: Variable not defined”
message, but got “Compile error: Ambiguous name detected: nam1”
message instead.

Scenario 2:
Sub Test()
Debug.Print nam3
End Sub

This did NOT generate a compile error, but printed “33” when executed.

Scenario 3:
Sub Test()
Dim nam3 As Long
nam3 = 99
Debug.Print nam3
End Sub

Of course, this one compiled without error and printed “99” on
execution.

In the past I’ve depended on the compiler to pick up missed
declarations, but it seems this can’t be relied on when Enums are
involved.

Any comments appreciated.

Regards,

Dave U



It also works the same way on 2007.

With the ambiguous name issue, you would need to refer to the Enum you want:

debug.print List1.nam1

I don't understand what you mean be a "missed declaration".

Hi Ron,

Thanks for your reply.

With the ambiguous name issue, you would need to refer to the Enum you want:
debug.print List1.nam1

Yes, I understand that, IF I was referring to an Enum variable.

I don't understand what you mean be a "missed declaration".

I think you mis-understood my point in this post. In the macro below
I have an un-declared variable "nam3". I would expect to get a
compile error , but I don't. It thinks I'm referencing List2.nam3.
On a large application this could be a real nuisance to locate.

Public Enum List2
nam1 = 11
nam3 = 33
End Enum

Sub Test()
Debug.Print nam3
End Sub

regards,

Dave U

Dave Unger wrote on 4/13/2011 :
I would expect to get a
compile error , but I don't. It thinks I'm referencing List2.nam3.
On a large application this could be a real nuisance to locate.

And this is precisely why Ron suggested you preface the var with its
enum name:

List2.nam3

This is a fully qualified ref to the var nam3. Specifying its enum name
is just good programming practice. It not only makes your code easier
to understand, there's also no ambiguity as to which nam3 var you're
refering to. Not to mention the added benefit of using Intellisense
while coding, there's really no reason to not preface the var with its
enum name.

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

On Wed, 13 Apr 2011 14:34:58 -0700 (PDT), Dave Unger wrote:

I think you mis-understood my point in this post. In the macro below
I have an un-declared variable "nam3". I would expect to get a
compile error , but I don't. It thinks I'm referencing List2.nam3.
On a large application this could be a real nuisance to locate.

Public Enum List2
nam1 = 11
nam3 = 33
End Enum

Sub Test()
Debug.Print nam3
End Sub

regards,

Dave U

I see what you mean. But this is not unique to user declared Enum's. It can also happen with other constants that are part of the system, but not explicitly declared. You don't get a compile error because the compiler can interpret the constant. One purpose behind Enum is so that you can set up your own set of constants. But neither these nor the vb constants are "reserved words", so if you use Dim them within a module, that will take precedence; and if you don't VB thinks you are calling a constant that has already been defined.

For example:

--------------------------------
Sub test()
debug.print xlErrNA
End Sub

-----------------------------
Sub test()
Dim xlErrNA As String

xlErrNA = "foobar"
Debug.Print xlErrNA
Debug.Print XlCVError.xlErrNA
End Sub

--------------------------------------------

On Apr 13, 2:34*pm, Dave Unger wrote:
I think you mis-understood my point in this post.
*In the macro below I have an un-declared variable "nam3".
[....]
It thinks I'm referencing List2.nam3.

I understand what you are trying to say. But I think __you__ are
missing the point.

The point is: apparently the enum name (list2) is not required in
order to reference an enum member as long as the enum member name is
unambigous.

The "undeclared variable" error means that a name has not been
declared in an applicable scope. But in your example, the name "nam3"
is indeed declared with an applicable scope (module level), given the
implied qualifier of "list2".

You might not like it. But that is the way it is.

It is not uncommon for VBA to have default qualifiers. In fact, you
probably rely on it. How many times have you written Range("a1")
instead of ActiveSheet.Range("a1")?

Hello,

Thanks to everyone who responded to this.

This one caught me by surprise.

I always fully qualify any Enum variable in my macros (List2.nam3), so
I guess I assumed it had to be that way.

What led me to this - I was writing a short macro to test a function,
and just happened to pick the variable "nam3" out of the air. I ran
the compiler to make sure everything was OK. Then I happened to
notice that I hadn't declared "nam3", but the compiler wasn't giving
me an error message.

So, what I'm saying, if this had gone un-noticed on a large project,
it would likely cause undesireable results that could be difficult to
track down.

Thanks again.

regards,

Dave U

On 13/04/2011 22:34, Dave Unger wrote:
Hi Ron,

Thanks for your reply.

With the ambiguous name issue, you would need to refer to the Enum you want:
debug.print List1.nam1

Yes, I understand that, IF I was referring to an Enum variable.

I don't understand what you mean be a "missed declaration".

I think you mis-understood my point in this post. In the macro below
I have an un-declared variable "nam3". I would expect to get a
compile error , but I don't. It thinks I'm referencing List2.nam3.
On a large application this could be a real nuisance to locate.

The system would fault you for attempting to assign to an Enum.

Public Enum List2
nam1 = 11
nam3 = 33
End Enum

Sub Test()
Debug.Print nam3
End Sub

You *have* defined the unambiguous symbol nam3 as one of your public
enums in List2.

I am slightly surprised that VBA doesn't warn when you have two enums
with the same name in different lists. It would be more interesting in
the Chinese usage if they were defined with different values.

Regards,
Martin Brown

Hi Martin,

Thanks for your reply.

This whole exercise has given me a new awareness re Enums, and
assigning members. I had erroneously assumed there was a "bug"
involved (a moment of panic?), turned out the "bug" was me. You, and
the other kind people, put me back on track, for which I'm very
grateful.

regards,

Dave U

You *have* defined the unambiguous symbol nam3 as one of your public
enums in List2.

I am slightly surprised that VBA doesn't warn when you have two enums
with the same name in different lists. It would be more interesting in
the Chinese usage if they were defined with different values.

Regards,
Martin Brown