The IDE already lets us specify the Enum data type (as long as it is SIGNED integer type).
If it allowed Unsigned types one could still use a signed integer type for those and of course the default type could stay what it is now which is just INTEGER.
Hmmm maybe it is because when enums were introduced the unsigned types did not exist… ( IIRC RB did not have Enums or unsigned types when I first started using it, but I don’t remember whatever features were added.)
BTW speaking of Datatype issues, Variant.Type code as listed in the docs does not support all the integer types…
This is the first time I wanted that and never noticed that were missing before…
Assign a byte to a variant and variant.type will say you assigned an Int32…
This is the type of stuff that really annoys me and wastes a lot of time for me
I come up with a design to handle something in a general manor that logically should work and start coding, but then I am often stymied, delayed or have to compromise functionality because of an incomplete or buggy Xojo feature implementation.
An interesting perspective on programming, but one that is doomed to fail… A design that fails to take account of the limitations of the implementation language is not really a design in my book, more of a dream really.
The use of constants in calculations is a widely used concept in most languages, but the use of enums is not something ive seen advocated anywhere.
[quote=437466:@James Dooley]An interesting perspective on programming, but one that is doomed to fail… A design that fails to take account of the limitations of the implementation language is not really a design in my book, more of a dream really.
Of course I take into account what Xojo can do…once I trip over the limitations…
Too often it falls short of logical/expected(even from documentation)/intuitive reasonable expectations.
I tend to be a through detail oriented person …and the mainframe/mini computer languages i taught myself on back in the day were like that too… and it is what I expect from a professional tool.
It’s not that there were no bugs or shortcomings back then … but language features tended to implemented much more completely/throughly … and that is how it should be.
The use of constants in calculations is a widely used concept in most languages, but the use of enums is not something ive seen advocated anywhere.[/quote]
Depends on the language. In Xojo I see them not only as a way of limiting possible values, but also for code/project organization and help keeping autocomplete lists from becoming too long by showing only relevant options.
[quote=437436:@Karen Atkocius]I wanted to define an Enum as an Uint8 (or Byte) but the IDE won’t let me… but it will let me define it as an int8…
Works fine here to change the enum type to pretty much any integer type in 2019r1
EDIT : in fact t works in XojoScript as well (which is unsurprising)
Enum foo As UInt8
Dim i As foo
Dim c As New myClass
c.i = myclass.foo.foovalue2
Select Case c.i
If you add this to an IDE script and press run you get a result printed
If you change the Enum type to “String” or some other non-integer type you get a compile error
I was using 2018R3 and there If I typed say UINT8 into the datatype field for an enum and hit return, it immediately changed back to integer… If instead click on the name field it stayed as UINT8 but the naviagator displayed it as integer… But inspecting it showed it to be UINT8
Just tried it in 2019R1 and the above issues are fixed BUT if I copy an Enum of type UINT8 and past it into another object the type changes to integer and that goes BOTH for the IDE and the inspector