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)
Select Case e
tf.Text = "This"
tf.Text = "There"
Select Case e
Case IsA e1
Case IsA e2
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.
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:
Operator_Convert(FromEnum As Thingies)
Operator_Convert(FromEnum As Doohickeys)
Operator_Convert() As Thingies
Operator_Convert() As Doohickeys
Sub SomeMethodThatTakesEnums(EnumValue As Intermediary)