I never quite understood why Xojo enums could not be type equivalent to their underlying integer type and I get caught out by the compiler most every time I use them.
I’m getting a little bored of typing integer every time i want to pass an enum to the framework and was wondering, is there a more elegant way than a clumsy explicit cast?
My first thought was to override the HeaderAt function. The following works fine for retrieving a value
MySubClassedListBox.HeaderAt(index as eColumns)
Return HeaderAt(Integer(index))
End Function
Where I’m stuck is coming up with a matching assignment method. Is there a way to assign to HeaderAt using an enum as the index without breaking the assignment syntax?
It may be I’m being dumb here and missing something obvious. (I spend too much time using other development dialects these days.)
Function ToInteger (Extends v As eColumns) As Integer
return integer( v )
End Function
// Elsewhere...
ListBox2.HeaderAt( eColumns.columnName.ToInteger ) = ...
Xojo enums are so mind boggling that I totally gave up on them. Constants are fine, they auto-complete, and are clearly understandable long after the code has been written. I group them with prefixes for a sort of pseudo-enum functionality.
Thank you @Andrew_Lambert. That looks like the magic rune I was searching for. And thank you all for your attention.
Yes I could use constants and I was using constants but the logical description of the problem fits an enum; a set of ordered values with an arbitrary identifier. I would much rather have clunky enums than no enums at all.
Enums should gain special properties in Xojo, to add more value to the language, and fix the current aberration of “binary enums” that aren’t enums and can’t be used anywhere.
And of course, a week after writing that I’ve fully embraced Enums and am implementing them left and right in all my projects, lol. They are indeed useful.