Enumerations aren't useable outside its class

Can someone help me with using enumeration outside its owner class. i get the error that there is no member with that name. however my enumeration is public

You must include the class name

Classname.enumName.Value
1 Like

i did

Uh… you can’t just call Animator.AddAnimation because it needs to be an instance.

You haven’t made a property or variable like this have you?

animator as Animator
1 Like

I find it helps beginners with comprehension if classes are prefixed with a c

animator as cAnimator
3 Likes

thanks alot. i didnt know that xojo isnt case sensitive

If EnumType is Public and is defined in App/MyApp, why can’t you use:

enumName
App.enumName / MyApp.enumName

…from a method within App?

Nor can you say “Using MyApp.EnumType”

It seems you MUST specify: EnumType.enumName

Because the type defines where to get the value.

Imagine if you had two enums:

myInts: with values of One, Two, Three, Four, Five
myBinary: with values of One, Two, Four, Eight, Sixteen

If the compiler allowed you to use just the values, how would it know which “One” or “Two” to use?

3 Likes

Well if your signature of a method is:
Function MyMethod(Type As MyApp.MyEnum) As Boolean

the compiler or parser can be made smarter so something like:
MyMethod(MyApp.MyEnum.One)

would preferrably become:
MyMethod(.One)
As the IDE and compiler already know what type to expect.

And for properties this would become:

Property MyType As MyApp.MyEnum

MyType = .One

In xojo this is not the case, but in many languages it can be done this way.

Here is a case for this to become a feature:
<https://xojo.com/issue/65935>

@Greg_O_Lone – I think I’m used to how C++ handles this: if you defined an enum type, or an enum class (C++11 and beyond), then there’s a lot of context involved in assignment or passing as a parameter. In the case of an anonymous enum (maybe not a good practice), then you wouldn’t be able to have two that are the same.

Also, in C++, you can put enum definitions inside a header file, and including that header file/ definition in multiple places doesn’t create a unique new definition. The end result is that I almost never have to preface a C++ enum with a namespace. Even within a class, if the enum happens to be defined in the class definition, it still doesn’t need the class namespace when referenced WITHIN the class.

So there are ways compilers can infer a lot about enums – I was just looking to reduce the bulk and improve readability in Xojo.

I suggest you add points to that case then, as this is not c++.

1 Like

@Greg_O – I hear you. I first wanted to confirm that Xojo DIDN’T have that feature, because of my lack of experience with Xojo. I’m collecting a list of suggestions, but I’ll also need to see that these are suggestions that haven’t already been made.

Certainly more confusing. If I just look at your lines, I won’t immediately remember what “one” is part of. I’ll have to move the mouse over “MyType” or “MyMethod” to see this is of type MyEnum.

If you name things well, you won’t have such issues, 3 examples:

Timer1.Runmode = .Off
If Thread1.RunModes = .Running Then Thread.Stop
Shell1.ExecuteMode = .Interactive

Pretty clear i’d think, i’m sure you directly understand this and it’s much shorter, less info to read and better to understand.

Having periods in the beginning of a statement just doesn’t look basic-like.
Granted, I understand your 3 examples, but I dislike them (no offense, of course).

Shorter, yes, although autocomplete makes writing longer lines easy. Less info to read, also true, but it can be “lacking info to read” as well; I can certainly make an example which, unlike your 3 above, are harder to understand. And “better to understand”… for me, definitively not; you think that because you’re accustomed to it, I bet.

I’d like it better without the “.” prefix. Just

Timer1.Runmode = Off

However, this is a change to the compiler that has the potential to go off the rails. They would have to test a huge amount of cases. The possibility of introducing bugs to the compiler makes me nervous.

With or without, the language would be easier imo to read than the long Name.EnumTypes.EnumVal.
So you are nervous about compiler changes, well i i’ve seen major compiler changes in other languages, and xojo can even implement this via the ide maybe just visual showing the short thing would internally change to the full long name (if it’s there, otherwise show an error).

As seen that way, I’d agree. However, you can always put your enumeration in a module to avoid the need of the first namespace (just EnumTypes.EnumVal).

You’d possibly get name conflicts or unclear naming probably if you work with many developers.