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
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.
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:
[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?
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:
[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.
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.
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.
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.
