I’d like a method that can handle multiple enumeration types via a single parameter along the lines of:
Public Sub showEnum(e as Variant)
//Either:
Select Case e
Case e1.this
tf.Text = "This"
Case e2.there
tf.Text = "There"
Else
End Select
//OR
Select Case e
Case IsA e1
...
Case IsA e2
...
Else
...
End Select
End Sub
The isA obviously won’t work as enum is not a class. Same with Interfaces.
I’ve thought about using overloading - new method for each enumeration type - but I have about 20 enums each with about 20 values - making this very cumbersome.
I thought enumeration was a specific number type - but the variant parameter just seems to contain an integer so the method cannot distinguish between enumeration types.
I doubt that you can do this in a single method. How about multiple methods with the same name but different parameter signature?
Public Sub showEnum(e As e1)
Public Sub showEnum(e As e2)
Yes, overloading, that’s feasible but with the number of locations I would have to do this it would become very cumbersome.
My current thinking is that I would have to use 1 enum, and a variant in the parameters. The first enum would define which of the enumeration types I am referring to, the variant (an integer) would then be compared to values in the referred to enum.
But only if the right way makes the code almost unreadable.
A bit more background might help. I was using a single enum to flag to the high levels of the app that a class property had changed - so that the app could reflect that change into other windows or areas where the property is used. Lower levels of the app would then filter out properties not relevant to them. The problem I was running into was that the enum for the class properties was about 180 items long - making it difficult to use - so I decided to break it down into enums for each class - of which there are about 20. But now I run into the problem described earlier, that I can’t process those different enums without more complex overloaded methods.
If there was another way to pass the information about class and property up and down the chain in a single set of parameters, that might resolve the issue more directly. I thought Introspection might be my friend but then I have to rely on manual typing of class and property names etc that can’t be checked by the compiler.
Could you not track the state within the class itself?
Maybe if you had a dictionary property that contained an entry for each class property + the date/time it was last updated you could then get any interested parties to check the dictionary to see what had changed. You could also use class constants to hold the property names to avoid mistyping them when coding.
This does rely on all code that changes the properties also updating the dictionary but you could enforce that by making the class properties private and using setter methods.
A possibility that occurred to me is to create an intermediary class that can automatically convert to/from the enum types, and use that as the parameter type:
Enum Thingies
Foo
Bar
Enum Doohickeys
Baz
Bat
Class Intermediary
Operator_Convert(FromEnum As Thingies)
Operator_Convert(FromEnum As Doohickeys)
Operator_Convert() As Thingies
Operator_Convert() As Doohickeys
End Class
----
Sub SomeMethodThatTakesEnums(EnumValue As Intermediary)
----
SomeMethod(Thingies.Foo)
SomeMethod(Doohickeys.Baz)
Create an intermediary class “clClassProperty” with overloaded constructors, one for each enum type accepting an enum for the class, and an enum for the property.
new classProperty( eClasses.classname, ePropertiesN.propertyname)
Also add overloaded get methods, one for each enum type, returning the associated enum for that class.