1. impossible dynamic use with RecordRef and FieldRef:
So far it is impossible to work properly with the enumerations RecordRef and FieldRef. You can find out which field has which data type, but the available possibilities regarding filtering are very modest. For example, we have built a very dynamic interface that makes it possible to assemble everything at runtime. We can't use this now, because we can't look into the enumeration. With the old options you could do this at least via the table "Field" and in "FieldRef" via the property "OptionString" or "OptionCaption". At the moment there is nothing adequate to replace this for enums.
2. enum metadata
Regarding point 1 it should be mentioned that it would be very practical if the enumerations also had their own metadata table, with which one could read out the inheritance hierarchy as well as the values and description.
3. higher number values
Another problem is that you can only create an enum on the basis of an integer. But we have the problem with some interfaces that we would need the BigInteger because some values are so high. In .NET I can simply create an enum for this based on the data type "Long". Could such a similar solution be imaginable in Business Central so that larger values can be used?
Comments
I think enums based on non-integer types would also be useful, for example Guid, Code, Text, Boolean.
Guid because sometimes it is useful to have unique identifier that is shared with external systems but at the same time used in code as a constant. Our app licensing module would benefit from this because our product IDs are Guids, but we register products using enum extension + interface which returns product ID.
Code/Text because it would be nice to have text constants which are also setup fields.
Boolean because it would allow for more readable code, e.g. SwitchLights(Lights::Off).
Category: Development
It would also be useful to have enums with base type Guid.
Our licensing functionality uses enum extensions to add products while we use Guids to identify products adding unecessary complexity to convert from enum values - integers to Guids.
This is rather annoying because when product is not installed the enum value is also not present so I cannot use it in code as a value.
Eg.
// in licensing module
enum 70302553 "LBCLIC Product" implements "LBCLIC Product V1"
{
Access = Public;
Extensible = true;
UnknownValueImplementation =
"LBCLIC Product V1" = "LBCLIC Unknown Product";
}
// in product app
enumextension 99100 "LBCLICDEMO LBCLIC Product" extends "LBCLIC Product"
{
value(99100; "LBCLICDEMO Demo Product")
{
Caption = 'Demo Product (SLE)';
Implementation =
// the implementation needs to return product ID Guid
"LBCLIC Product V1" = "LBCLICDEMO App Licensing";
}
}
While instead it could be:
// in licensing module
enum 70302553 "LBCLIC Product" implements "LBCLIC Product V1"
{
Access = Public;
Extensible = true;
BaseType = Guid;
UnknownValueImplementation =
"LBCLIC Product V1" = "LBCLIC Unknown Product";
}
// in product app
enumextension 99100 "LBCLICDEMO LBCLIC Product" extends "LBCLIC Product"
{
value('54f439a5-c267-44e9-9ca8-0bb8d927e901'; "LBCLICDEMO Demo Product")
{
Caption = 'Demo Product (SLE)';
Implementation =
// the implementation does not need to return product ID Guid
"LBCLIC Product V1" = "LBCLICDEMO App Licensing";
}
}
I don't see why Code/Text couldn't be used as well. This would eliminate hardcoding especially in apps based on old code which has plain strings littered all over the place.
Category: Development
Also virtual table 2000000041 "Field" should have column "Type" = Type::Enum...
Category: Development
Please, should FieldRef return "Type = FieldType::Enum" for Enum instead "FieldType::Option"?
Also FieldRef could have method GetEnumTypeName() i.e. "Gen. Journal Account Type".
Currently it is not possible to dynamically determine the enum type for field.
Category: Development
> we can't look into the enumeration. With the old options you could do this at least via the table "Field" and in "FieldRef" via the property "OptionString" or "OptionCaption". At the moment there is nothing adequate to replace this for enums.
As of right now, Fields of type Enum have FieldType.Option, and you can use FieldRef.OptionMembers() to get the names of the available enumerated values as a comma-separated string, as with Options.
There are also the following methods on FieldRef, from which you can loop the available names/ordinals and do dynamic stuff that way. It's a shame they don't return Lists for easier use, or offer a way to get Captions. But it's better than nothing, and I suspect better than what you were aware ;-)
EnumValueCount
GetEnumValueCaption
GetEnumValueCaptionFromOrdinalValue
GetEnumValueName
GetEnumValueNameFromOrdinalValue
GetEnumValueOrdinal
Category: Development
How about an EnumRef that would function similarly to RecordRef and FieldRef. It would contain all of the information about a given Enumeration.
Category: Development
Business Central Team (administrator)
Thank you for your feedback. We are considering adding it to our longer term roadmap.