Al: Numeric value for 'Enum'

[hemisphera]

There are a few problems I face when using the new Enum type:

1. An Enum cannot be converted to or from Integer. Even though every value is uniquely identified by an integer value, ALC currently does not allow converting to or from Integer. I dearly hope this is a bug and/or will be supported in future versions.
2. Because of the above, we currently do not have any means to 'extract' the numeric value of a given Enum. One of the advantages of the Enum type is that I can have an enum value with - say - ID 40 without having the need to declare 40 empty options. Take interfaces to external systems as an example. At one point or another I will have to import from / export to Integer so I need the numeric value.

[esbenk]

It is by design that there is no implicit conversion to/from integer. We want to avoid the relaxed conversions that characterizes options.

We will add functionality to explicitly convert to/from enums in a future update.

For backwards compatibility with C/AL we support implicit conversion to/from the Option type. We may restrict that in the future when C/SIDE & C/AL is gone.

[hemisphera]

OK, I can understand that. The point is though: at the end of the day, an enum is nothing more than a "named" integer and it is also stored as such in the DB.

Having said that ... I don't necessarily need a relaxed conversion. I would be more than happy with the following:

var ZheEnum: Enum MyEnum; ZheInt: Integer; begin ZheInt := ZheEnum::FirstItem.Value; ZheEnum := ZheEnum.Evaluate(20); end;

... or something similar. This way it's no longer as relaxed as options were and you have the possibility to execute runtime checks during Evaluate to check if the value actually exists.

[esbenk]

It is functionality like that, we plan for a future update.

[JavierFuentes]

@StanislawStempin and @esbenk

It is by design that there is no implicit conversion to/from integer. We want to avoid the relaxed conversions that characterizes options.

We will add functionality to explicitly convert to/from enums in a future update.

For backwards compatibility with C/AL we support implicit conversion to/from the Option type. We may restrict that in the future when C/SIDE & C/AL is gone.

Assign Options to Integers has advantages I wouldn't like to loose with Enums....

For example, actually we can iterate with a FOR Loop with Options and Integers.... with Enums I would like to do the same and with a FOREACH Loop too, but compiler does this error:

_A ‘foreach’ statement can only be used with an expression of an enumerable type._

I would like to do things like these ones:

Message(Format(myEnum::EnumLabelX.value));
Message(myEnum::EnumLabelY.label);
Message(myEnum::EnumLabelZ.labelML);

for intValue := 0 to myEnum::EnumValueN.value do begin
   // do something with Integers
end;

foreach intValue in myEnum.Values() do begin
   // do something with Integers
end;

foreach txtValue in myEnum.Labels() do begin
   // do something with Text Caption in en-US base Language
end;

foreach txtValue in myEnum.LabelsML() do begin
   // do something with Text Caption, in User active Language
end;

[esbenk]

We will add programmatic access to enum values in a (near) future update. This is especially important for the Extensible flavour where you at design-time don't know all possible values.

[BrianThorChristensen]

You can use:
evaluate(int, format(enum, 0, 9))
and
evaluate(enum, format(int))

[GreatScott000]

@esbenk Any information on "programmatic access to enum values"?

[esbenk]

No. Maybe next release, but it could slip.

[navdotnetreqs]

Yeah, we need this too. I see there is enum.asinteger(), but how to set the enum without knowing the values during coding? Eg. loop the enums and select the third.

[esbenk]

It is possible to get the Enum Names and Ordinals using either the specific Enum or through a FieldRef.