Al: Extendable Option type

[FSharpCSharp]

Microsoft Dynamics NAV contains various standard tables, which are uniquely identifiable by option fields. For example, this is the table "Sales Header" and "Sales Line". In the old extension framework 1.0 it was still possible to extend option fields of tables, not nice, but you could.

Unfortunately, it is not yet possible. In my opinion, however, it is also very problematic because option is managed internally as an integer. And if several extensions extend the option fields, it can only lead to problems.

So I ask the question of whether there is a reasonable concept for dealing with this problem.

[pzentner]

there are two different concepts that would make more sense and probably even a combination of them.

it would make sense to replace options with enumeration, which those are essentially already anyway. the extension object range could be used to extend the enumeration with unique ids.

then you could use the json resource files to provide the captions, even translated, for the enumerations

[FSharpCSharp]

That sounds like a very interesting new solution for Dynamics NAV. The enumerations provide at least one adequate solution for this purpose, in order to be able to depict such cases in a meaningful way. But an enumeration alone would not solve the problems, which also occur with the options fields. Just remember that there are a lot of CASE XYZ OF blocks in the current objects. Wouldn't it make more sense to create a separate inherited object for each document type? In this case, the existing logic could be adopted. Also, the overrides of logic already proposed in other issues would also make the best use here. For the current extension concept, I see it as problematic if the code contains a lot of CASE blocks, because you cannot publish events in thousands of places.

[esbenk]

We are aware of this problem - the combination of options and case statements. We are investigating different solutions. They all still require the extensibility to be designed into the base-app.

[epernst]

What is the status on extending option fields? It's really a returning issue.
And also consider that today we have a lot of code which uses the integer value and have functionality that uses OptionValue += 1 to make it go to the next option. Or checking that the new value always is higher than the previous.

[esbenk]

We are investigating how create the best solution that is compatible with existing code and at the same time supports extensibility.

We know this is an important area - and it is not forgotten. We don't have a timeline for this right now, but it is on the top of the list for extensibility features.

[pzentner]

IMO, you have two options

1. look at options as enums with captions. this would support the current way of usage and then extend it similarly, using the allowed object range for valid integer values for the different options, which would allow extensibility.

2. get away from using it as an integer, which is not really good coding practice anyway, although it's easy and done often. treat it as a collection of unique option names plus option captions

or, replace everything with tables of type option that are displayed a special way when defined as a table relation and cannot be edited on runtime. daya would have to be defined via packagedata or something at design time.

[esbenk]

Extensible enums shipped in BC Fall 18 release.