REALenum for a class or control

It looks like REALenum is recognized in code completion but once the compiler gets involved it simply does not recognize the enumeration. Pretty disturbing, also because SharedMethods in a control still don’t work feedback://showreport?report_id=47903, but can be worked around my declaring a subclass of the control and register the shared methods in that subclass. I guess it is only me complaining about these kind of issues, but it diminishes proper development of plugins. REALenums only work in a module, thus making sure that stuff specific for a plugin control or class is being seen all over the place. Yay! Containment should be the mantra as far as I can judge it.

There is nothing wrong with Enums on classes at least. I use them extensively. For controls I do not know.

I avoid them and just make constants.

I prefer the way Björn does enums with plugins like ExcelWriter. It makes it easier for me to know for sure the value I’m sending is the correct one.

Enums are explicit. Whereas constants can be used improperly.

Thanks for the heads up. Did some thorough checking, and indeed the REALenum is ok for a class and even a control. But the sharedMethods for a control is not possible as was confirmed two years ago.


I’d love to use more enums, but can you define them globally for transition?

e.g. instead of

kSomeValue = 1

make an enum with kSomeValue and than just use kSomeValue without writing MyModule.MyEnum.kSomeValue?

You cannot as far as I know but you can do myClass.MyEnum.SomeValue.

But I think that’s a good thing to scope it. I for example have Alignment in Excel plugin and Alignment in PDF and alignment in new plugin that is in the works, each is unrelated to each other. Scoping them is a good thing

You would think that in a Module the flag REALScopeGlobal should do the trick, but it does not. It (for obvious reasons, I think) does not when the enum is attached to class or control, which then behaves as REALScopePublic. Guess that REALScopeGlobal is superfluous.

I don’t mind (and prefer) the namespacing though. Then I know that the enum belongs to the plugin I’m using.

The problem is transition.

e.g. if I have a constant named kTest in a class MyClass and user pass that to a method, they would write

dim c as myclass
c.test myclass.kTest

or similar.
Now I would love to move that into an enum. But if they now need to add the name of the enum, it would break code.
In C the values for enums are global, so you can refer them without naming enum. You would simply write kTest and get the value as enum type.

[quote=423353:@Christian Schmitz]The problem is transition.

Now I would love to move that into an enum. But if they now need to add the name of the enum, it would break code.
I get that. I for one am not afraid of updating code; but it’s the general Xojo Mojo that doing any kind of updating is the end of the world. Doesn’t mean I love your plugins any less!