64
In the daily programming the handling of the newly introduced enumerations and enum extensions is not exactly conclusive. I think the idea is generally good, but unfortunately there are some essential points missing:
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?
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?
STATUS DETAILS
Under Review
Business Central Team (administrator)
Thank you for your feedback. We are considering adding it to our longer term roadmap.