The limitation of enum

I haven’t messed with enums before but it seems like it could be useful. I like the code completion aspect of: enumname.enumvalue.

But, am I correct that given:

enum my_colors green = 1 red = 2

you will always need companion code elsewhere that defines the reverse relationship?

select case x case 1 return "green" case 2 return "red"

Based on my searching of the forums, anytime you add one color in the above example, you’ll need to make two entries to account for it? Ex: blue = 3, 3 = blue. Or am I missing some nifty trick that doesn’t require duplicated work with enums?

No nifty trick there, enum’s only have one value like a constant, which is in your case a number.
If you want to get a text it need’s to come from somewhere, however you implement this it need’s to stay maintained anyhow.

On a side note, as of 2014r3, enums can no longer be treated as numbers so they aren’t really like constants any more. You will need to do some casting to do things like comparisons, addition, etc.

For example, if myChoice is an integer (say that you read it in from a data file), you can’t do this:
if myChoice = my_colors.green

You now have to do:
if my_colors(myChoice) = my_colors.green

A weak example, but I’m tired. LOL

Enums aren’t “numbers”.
They are a new data type with all the semantics that carries - they just happen to be based on a underlying numeric type.

The companion code would be the more readable

dim x as myEnum
...
select case x
case myEnum.green
   return "green"
case myEnum.red
   return "red"

My main goal is to have something that autocompletes, like my_colors.green, also gives me the text “green”, and due to laziness/forgetfulness, something where I’d only have to define “green” once.

In actuality, the colors I’m referring to are the names of console apps I’ve created. So autocompleting my_apps.name_of_my app would let me know I’ve defined name_of_my_app and getting the text “name_of_my_app” lets me turn around and access it via a shell. The desire to only define name_of_my_app only once is, besides laziness, would remove the duplication of work in different areas and avoid things like misspelling errors on my part.

You could use constants instead. It sounds like they actually might be what you are looking for.

Yes that does look like a much simpler approach that does what I was hoping for. Thank you.

I have made a colour module with all the websafe colours in it. I’ll be off my computer till Friday but can send it to you if you like.

Does anyone still use web safe colors?

It is a shame that enums are their own data type and that you cant assign a type to them, i’m not really sure of the reason for this. I use constants because of this. I like to have ‘themed’ apps which I just set up all the custom colors in the IDE and assign them to contants in my app class such as:

App.ThemeColorWindowText = &c000000 App.ThemeColorWindowColor = &cFEFECB App.ThemeColorLightWindowText = &c444444

An so on…

I would much prefer to be able to create this as an enum (perhaps because I am ex VB):

Enum ThemeColors as Color WindowColor = &cFEFECB LightWindowText = &c444444 End Enum

[quote=153035:@Mike Charlesworth]I would much prefer to be able to create this as an enum (perhaps because I am ex VB):

Enum ThemeColors as Color WindowColor = &cFEFECB LightWindowText = &c444444 End Enum[/quote]
How is that so different from using a module ThemeColours with constants WindowColour, LightWindowText etc?

Encapsulation :slight_smile:

I was not discussing their differences, rather my preferences:

Methinks Encapsulation is overrated in this case :wink:

A value typed as enum can accept only the enum values
If you use constants then you can set as value not only the constants.

So in the color example if you write

Enum ThemeColors as Color WindowColor = &cFEFECB LightWindowText = &c444444 End Enum
and some property of type ThemeColors then you want only the colors defined in the ThemeColors enum.
If you write constants as:

kWindowColor = &cFEFECB
kLightWindowText = &c444444

and a property as color then you CAN assign the constants but you CAN assign any other color.

[quote=153056:@Antonio Rinaldi]A value typed as enum can accept only the enum values
If you use constants then you can set as value not only the constants.[/quote]
I know. I’d still content that an enum is complete overkill in this case.

An enum’s main purpose (as far as I understand them) is to restrict input to valid values. For example security levels.

But in this colour example? Complete overkill.

This may be even more overkill for the color use case, but FWIW…

I use enums quite a bit for various purposes, and one of the things I often do is create dictionaries to translate the enum value.

// set up the enum
enum colors
Green
Blue
Red

// initialize dictionaries somewhere early in the code (e.g. app.open)

Dim ColorVal As New Dictionary
ColorVal.value(colors.Green) = &c00ff00
ColorVal.value(colors.Blue) = &c0000ff
ColorVal.value(colors.Red) = &cff0000

Dim ColorNames As New Dictionary
ColorNames.value(colors.Green) = "Green"
ColorNames.value(colors.Blue) = "Blue"
ColorNames.value(colors.Red) = "Red"

// to leverage these values later in the code you can do things like this...

Dim c As Color
c = colorval.value(color.green)

// or

For i As Integer = 0 to 2
PopupMenu1.AddRow ColorNames.value(colors(i))
PopupMenu1.RowTag(PopupMenu.ListCount-1) = ColorVal.value(colors(i))
Next

[quote=153066:@Markus Winter]I know. I’d still content that an enum is complete overkill in this case.

An enum’s main purpose (as far as I understand them) is to restrict input to valid values. For example security levels.

But in this colour example? Complete overkill.[/quote]

Markus, Why is this overkill? For a start this is purely theoretical as enumerations cannot be typed as in my example so this conversation is for arguments sake only but I do not see your point.

From a typing point of view the constants declaration is about the same as the enum declaration in terms of pressing keys on the keyboard. From a use point of view setting a color would be:

MyItem.BackColor = App.ThemeColorWindowText

or

MyItem.BackColor = ThemeColors.WindowText

SO… I don’t see how this is overkill, just a different approach and one of user preference which was my original argument.

feedback://showreport?report_id=35963

I absolutely agree. I was hoping with the new framework they would finally take the time to address this (they did not).
We need two primary functions:
1)Getting the string value of any enum:

myClass.myEnum.stringValue

2)Getting a list of all the available Enums of a type. Adding the Enumerable interface would be very helpful. That way we could do:

ForEach anEnum as myClass.myEnum in myClass.myEnum ... 

Even if these two don’t exist. The very least we would need is for the EnumerationInfo of Introspection to also contain a way to get the string values. At least then it would be trivial to add the other 2 functionalities.

Hey look markus:

If you have a set of unchanging values that are logically related to each other, you can define them together in an enumeration. This provides meaningful names for the enumeration and its members, which are easier to remember than their values. You can then use the enumeration members in many places in your code.

Public Enum InterfaceColors MistyRose = &HE1E4FF& SlateGray = &H908070& DodgerBlue = &HFF901E& DeepSkyBlue = &HFFBF00& SpringGreen = &H7FFF00& ForestGreen = &H228B22& Goldenrod = &H20A5DA& Firebrick = &H2222B2& End Enum

Straight from Microsofts VB site, but hey what do they know… Overkill.

For those that are interested though, have a look at the VB Enum, this is what I was talking about and what I miss with the Xojo Enum

http://msdn.microsoft.com/en-us/library/8h84wky1.aspx