When is an enum not an enum?

I may be misunderstanding what is meant by a datatype but:

What should the expected output be from the following code:?


di = New Dictionary

di.Value(type1.a) = "a"
di.Value(type1.b) = "b"
di.Value(type1.c) = "c"
di.Value(type1.d) = "d"

di.Value(type2.e) = "e"
di.Value(type2.f) = "f"
di.Value(type2.g) = "g"
di.Value(type2.h) = "h"

Var ss() As String
For Each v As Variant In di.Values
  ss.add v.StringValue
Next
textarea1.Text = join(ss, ",")

Where type1 and type2 are different enums.

The answer I get is e,f,g,h as the dictionary just saves the enum as its integer value, whereas I was hoping for a,b,c,d,e,f,g,h.

An enum give a list of labels to some base value. Such value usually is a Integer. So it is possible to have infinite different enums with the same values.

So the answer for your question is “depends”

First you need to show us those enums definitions.

But let me assume a default simple definition where type1 a to d = 0 to 3 and type2 e to h = 0 to 3

The result should be “e,f,g,h”

To get what you wanted, your definitions should be:

Public Enum type1
a
b
c
d
End Enum

Public Enum type2
e = 4
f
g
h
End Enum
1 Like

Thanks Rick. Even after 10 years I’m still learning basics.

I’ve solved it in a slightly different way using extends for each enum to add a constant range for each enum. This allows me to add or remove enums without having to worry about renumbering.


di = New Dictionary

di.Value(type1.a.tointeger) = "a"
di.Value(type1.b.tointeger) = "b"
di.Value(type1.c.tointeger) = "c"
di.Value(type1.d.tointeger) = "d"

di.Value(type2.e.tointeger) = "e"
di.Value(type2.f.tointeger) = "f"
di.Value(type2.g.tointeger) = "g"
di.Value(type2.h.tointeger) = "h"

Var ss() As String
For Each v As Variant In di.Values
  ss.add v.StringValue
Next
textarea1.Text = join(ss, ",")


Public Function toInteger(extends e as type1) As Integer
  return 100 + integer(e)
End Function

Public Function toInteger(extends e as type2) As Integer
  return 200 + integer(e)
End Function

I think you may be misusing enums. There’s got to be a better approach. What problem are you trying to sove?

You appear to be using two different enum types in the same context to represent the same information. Maybe this is just an example to illustrate what you’ve noticed in some other context, but that seems like an anti-pattern to me.

Yes, this is just an example to illustrate that the enums are saved as integers in a dictionary. The actual code does nothing like this example.

In my code I have several different areas of code, each with their own enums that define particular events. As I build the code I want the ability to drop in different parts of code, separately tested, that include their own enum.events. But all the enum.events can be sent to a common dispatching structure to allow separation of UI and data processing. Rather than using Variants, I want the code to be a bit more auto-completing and testing in the IDE.

So for each area of code, I had defined its own enums, not realising at the time that they would lose their identify when put into a dictionary. So by adding a constant range to each enum, I can use common code.

You’re setting the dictionary values to string constants. The fact that the keys are enums or anything else is irrelevant - the values should be “a” - “h”. If you were collecting the keys, then I could see maybe integers showing up. Something seems wrong here.

You might consider using string constants instead of enumerations. This would let you namespace them, eliminating name conflicts:

fooClass.kProcessDataCommandKey = "fooClass.ProcessData"
1 Like

I think James and Rick are right, the enums assigned to the Dictionary are saving the keys as Integers. If both Enums have no assigned values, then the default range for each set is 0, 1, 2, 3.

So when the second set of Enums are being assigned to the Dictionary, they are overriding the values of the first set, which is why the results were e, f, g, h.

I think there is only 4 entries in the Dictionary, not 8.

1 Like

I guess that would also work - but I like enums as they are more compact in the IDE - and, because they sit in their own Module, they are easy to refer to.

I think the answer is that enums are for ease of IDE and compiling, whereas they are just integers when compiled.

That has always been the case.

1 Like

That’s expected. I misunderstood the OP, read too quickly.

1 Like