A little confused about Enumerations

[The Fire Snake]

Hi guys. I am trying to wrap my head around this concept and getting a little confused. I think I understand their purpose; to be able to use constants in your code with human readable names instead of obscure numerical values to make your code more readable. Is there any other basic purpose than this?

The other main thing that is confusing me is how to use them. I find their use very strange. I wrote a little test program and I need your help. See below for the test program. When I execute the code below it works and prints "param = 1" but I am confused on the types of what I am passing and what I am getting.

Am I passing the Enum value of "Hi" properly in my call to TestEnum? Do I instead create a variable of type Greeting and pass that? Also looking at the first line of the definition of TestEnum I am expecting the value of Integer for param1. Is this correct or should I have declared it as an object of type Greeting? I just find this very confusing. Thanks.

Public Enum Greeting
Hi = 1
Bye = 2
End Enum

Public Class MyTestClass

Private Sub Parent()
   TestEnum(Greeting.Hi)
End Sub

Private Sub TestEnum(Dim param1 as Integer)
   Msgbox("param1 = " & param1)
End Sub

End Class

[NickThissen]

It looks like you wrote that code outside of the designer because there's a "silly" mistake in the param1 declaration that would not have compiled. I assume you mean "ByVal" instead of "dim" there, correct?

Anyway, the 'error' is that you require param1 to be of type Integer. You should require it to be of type Greeting if you want to pass a Greeting.

An enumeration is just a type like any other. However, enumerations have an 'underlying type' (not sure how to call that) which is an Integer. The first value in your enumeration for example has value 1, and the second has value 2 (you could have used 28 and 982 if you wanted). For this reason, enumerations can be converted to integers (and the other way around too). I think that's the reason that you code compiled in the first place. VB is implicitly converting the Greetings.Hi value to an integer (which is 1 by your enum declaration). If you turn Option Strict On (google it or search this forum) then I think it will not let you compile.

So the only thing you need to change is the TestEnum method signature, to this:

Private Sub TestEnum(ByVal param1 as Greeting)

[The Fire Snake]

It looks like you wrote that code outside of the designer because there's a "silly" mistake in the param1 declaration that would not have compiled. I assume you mean "ByVal" instead of "dim" there, correct?

Yes, you are right. I wrote this code outside the editor paraphrasing what I had. Just a typo.

Anyway, the 'error' is that you require param1 to be of type Integer. You should require it to be of type Greeting if you want to pass a Greeting.

An enumeration is just a type like any other. However, enumerations have an 'underlying type' (not sure how to call that) which is an Integer. The first value in your enumeration for example has value 1, and the second has value 2 (you could have used 28 and 982 if you wanted). For this reason, enumerations can be converted to integers (and the other way around too). I think that's the reason that you code compiled in the first place. VB is implicitly converting the Greetings.Hi value to an integer (which is 1 by your enum declaration). If you turn Option Strict On (google it or search this forum) then I think it will not let you compile.

So the only thing you need to change is the TestEnum method signature, to this:

Private Sub TestEnum(ByVal param1 as Greeting)

Ok, you hit the nail on the head. I think this is the heart of my confusion. The implicit conversion is exactly what I wanted to avoid, I knew that was what was going on since when I change the type from Greeting to Integer I got it to work with the same results. So here is where I am confused. I understand the concept of classes and there members. Doesn't the enum kind of work the same way? Aren't the Hi and Bye like members that have a value assigned to them? I had read and knew about the "underlying" type you mentioned and that was what made me think that the Hi and Bye were Integer values, hence my use of Integer for the type of param1 in the TestEnum method I wrote. This is bizarre to me. I guess I need some sleep or something or I am just retarded

So Greeting is an enum and so is Greeting.Hi and Greeting.bye??

[NickThissen]

So Greeting is an enum and so is Greeting.Hi and Greeting.bye??

No. Greeting is an Enum, and Hi and Bye are its members. You can think of an Enum as a class (or possibly structure) with constant members, for example:

Public Class FakeEnum
   Public Shared Const Hi As Integer = 1
   Public Shared Const Bye As Integer = 2
End Class

With that class you can get the same functionality. However, I wouldn't dare to say that they are the same (they are most probably not), but it might help to think about it that way.

Did you read the MSDN documentation? It explains it pretty well, albeit a little technical:
http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx

[The Fire Snake]

No. Greeting is an Enum, and Hi and Bye are its members. You can think of an Enum as a class (or possibly structure) with constant members, for example:

Public Class FakeEnum
   Public Shared Const Hi As Integer = 1
   Public Shared Const Bye As Integer = 2
End Class

With that class you can get the same functionality. However, I wouldn't dare to say that they are the same (they are most probably not), but it might help to think about it that way.

Ok. This is exactly how I was thinking about Enums. If this is the case then why is Greeting.Hi seen as an Enum? From your code snippet above it is an Integer. How can it be both?

For example lets say that the Greeting enum was implemented as you mention above(I know that this might not be a 100% true) and I wanted to access the Hi member. I would do something like FakeEnum.Hi, where it's type would be Integer, not something else. Then if I wanted to pass it to a method I would do the following(see call and method signature it calls):

' Call to method
TestEnum(FakeEnum.Hi)

' Signature of the method called
Public Sub TestEnum(ByVal p1 as Integer)
.....
End Sub

I would not do the following(or it makes no sense to me to do it this way):

' Call to method
TestEnum(FakeEnum.Hi)

' Signature of the method called
Public Sub TestEnum(ByVal p1 as FakeEnum)
.....
End Sub

I read MSDN but I am missing something...

[keystone_paul]

That code shouldn't actually work because you can't put Dim in a parameter definition but I assume thats a copy and paste error.

You can actually define a datatype for your enumeration so it would be clearer if you did this :

    Public Enum Greeting As Integer
        Hi = 1
        Bye = 2
    End Enum

That ought to make things more obvious. Note though that there are limited types available for enums : SByte, Byte, Short, UShort, Integer, UInteger, Long, and ULong.

Are you using Option Strict by the way?

[The Fire Snake]

That code shouldn't actually work because you can't put Dim in a parameter definition but I assume thats a copy and paste error.

You can actually define a datatype for your enumeration so it would be clearer if you did this :

    Public Enum Greeting As Integer
        Hi = 1
        Bye = 2
    End Enum

That ought to make things more obvious. Note though that there are limited types available for enums : SByte, Byte, Short, UShort, Integer, UInteger, Long, and ULong.

Are you using Option Strict by the way?

I don't think so. How can I check?

[techgnome]

you can do either way.... enums are more for the developer... so that we don't have to remember that a value of 1 means one thing, while a value of 2 means something else. Even MessageBox uses Enums.... as you go through the options, like the YesNoCancel ... .that's an enum value.

as to if you want to declare the parameter as integer or the enum type... that's up to you... decl;aring it as the enum type gives you the intellisnse of the enum values when you go to use the function. If you declare it as an integer... you cna still use the enum, but then you don't get the values in a drop down.

Hope that made sense.

-tg

[NickThissen]

Another thing. What are you expecting the output of the TestEnum message box to be? If you expect "param1" to show "param1 = 1" then you should keep using what you have now. If you expect it to be "param1 = Hi" however you should use the ToString function:

Private Sub TestEnum(ByVal param1 as Greeting)
   Msgbox("param1 = " & param1.ToString())
End Sub

[The Fire Snake]

Another thing. What are you expecting the output of the TestEnum message box to be? If you expect "param1" to show "param1 = 1" then you should keep using what you have now. If you expect it to be "param1 = Hi" however you should use the ToString function:

Private Sub TestEnum(ByVal param1 as Greeting)
   Msgbox("param1 = " & param1.ToString())
End Sub

I was expecting the output of the message box to be "param1 = 1". Thanks for the info on the ToString method in regards to enums. That can certainly come in handy.

[NickThissen]

I was expecting the output of the message box to be "param1 = 1". Thanks for the info on the ToString method in regards to enums. That can certainly come in handy.

Well in that case what you were doing was technically correct (with option strict off), but still I wouldn't recommend it. With option strict on by the way you should have made the call differently, like so:

TestEnum(CInt(Greetings.Hi))

But if you do that, you loose all the advantages of having an enum in the first place! You could just as well use in integer in that case.

[keystone_paul]

If you look on the Project Properties dialog under the compile tab it will tell you.

By default this is off but it really ought to be on. Setting this option will prevent implicit conversions and highlight issues of type conflicts.

This does make it easier to see whether things you are passing in to a procedure that expects an integer really is an integer or just something that will pass as an integer.

[The Fire Snake]

If you look on the Project Properties dialog under the compile tab it will tell you.

By default this is off but it really ought to be on. Setting this option will prevent implicit conversions and highlight issues of type conflicts.

This does make it easier to see whether things you are passing in to a procedure that expects an integer really is an integer or just something that will pass as an integer.

Ok found it thanks. Here are my settings:
Option explicit = On
Option strict = Off
Option infer = On

I hesitate to make the changes to these values since the projects I am working in are shared by many other developers. Do these settings apply to my personal environment or does it effect the project file? I can't afford to screw up others.

[NickThissen]

Hi is not an enumeration, it is a member of an enumeration. There's a difference. The members have values of a specific type (in the default case: integer).

Your example is exactly where the similarity between an enum and a class with constant members breaks down.

If you want to pass a value of an enum to some function (or if you want to store it in a variable) you simply tell that function (or variable) "I want a value that exists in this enum". But the function will accept any Integer. It is nothing but a 'help tool' to tell the developer which possible values he can use.

For example, in your enum example, you can even pass the value 3 (when option strict is off) which is not even a value in your enum:

    Public Enum Greeting
        Hi = 1
        Bye = 2
    End Enum

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        TestEnum(3)
    End Sub

    Private Sub TestEnum(ByVal g As Greeting)
        MsgBox(g)
    End Sub

The MsgBox will happily show 3. Even if you convert the 3 to type Greeting explicitly it does not error, and displays 3. Greeting is an Integer, just with a different name.

So an enum is not a class or anything. It's just a tool that helps developers. It is perfectly valid to use Integers, I am pretty sure the compiled code will look the same, but using enums is, in some cases, much easier.


I don't know how to explain this any other way, lol. The name of the enum is only there to group constants together. When you use "Greeting.Hi", you don't mean "the Hi member of an object (instance) called Greeting", you mean "the value that I've given Hi in the list of Greetings".

You could also do this for example:

Public Enum CarToSell
   Volvo = 0
   Peugeot = 1
   BMW = 2
End Enum

Public Enum CarsToBuy
   Audi = 0
   BMW = 1
   Ferrari = 2
End Enum

Now, CarsToSell.BMW has a different value then CarsToBuy.BMW, even though they have the same name. If you used constants, you should have given them two different names.

When you now type "CarsToBuy.", VB will show the Intellisense list with the available options and their values. That is why enums are useful, because you don't have to remember each value, or look it up every time you want to use it.