Enumerations Shared Between Classes

Syntec

If I have myCustomTextField As CustomControl, and myCustomCheckBox As CustomControl

myCustomTextField defines Position Enumeration with Above = 0 And Below = 1
myCustomCheckBox defines Position Enumeration with Left = 0 And Right = 1

whichever customcontrol was added to the project last, overwrites the previous Enumeration, if myCustomTextField was added first, then when myCustomCheckBox is added to the project, myCustomTextField only sees Left and Right options for enum position. It appears enums are defined globally, is this the intended behaviour?

bgrommes

Syntec It appears enums are defined globally, is this the intended behaviour?

Where are the enums in the project tree? IIRC you can put an enum in Shared, which would be global, or embed within the relevant class. I'm at the wrong machine at the moment to verify.

Syntec

bgrommes In the classes themselves, which I why I think it is a bug

Garry

You’re right. This was a bug, and it has now been fixed.

Enumerations declared inside a class are scoped to that class. It is valid for both CustomTextField and CustomCheckBox to define their own Position enumeration. Within each class, the short name Position should resolve to that class’s enumeration. Outside the class, the qualified names CustomTextField.Position and CustomCheckBox.Position can be used.

The compiler and Studio were incorrectly allowing one nested enumeration’s short name to collide with the other, so the result could depend on source ordering. The fix covers type checking, compiled default values, Studio completions, and property-editor suggestions.

This will be included in the next release: Nested enumerations with the same name no longer collide between classes.

Thanks for reporting it.

Syntec

Garry Hey Garry, With the recent release Studio now says "[Error] SYNButton.Paint Line 10: Type name 'State' is ambiguous between nested enumerations. Use a fully qualified name: 'SYNControl.State', 'SYNWindowTitleBar.State'." Is the intent to have specify class.Enum within a class itself, shouldn't this resolve to the class specific enum?

Garry

This is a regression. Apologies.

It has been fixed for the next release.

Syntec

Garry Thanks Garry, I will have to go back and remove all the fully qualified names I added to make it work 😛

Garry

Doh! Sorry about that!