Last week, I had to do a considerably small change in one of our "Tools". Considerably ... I had to add 4 options to an option field ... and I had to put it in between other option values. First reaction: I don't like that. Second reaction: let's put it at the end to avoid problems (which cascade in other problems and so forth). I did not want to put it at the end of the option values, because the values just did not belong there... .
Exporting all (changed) objects to a text-based file, and start file/replace, can help you do this.
I'll try to explain:
First of all, internally (once you saved a compiled version of an object), NAV works with the integer values of an option (as well as fields, by the way). For example:
IF lrecItem."Costing Method" = lrecItem."Costing Method"::"FIFO" THEN;
IF lrecItem."Costing Method" = lrecItem."Costing Method"::waldo THEN;
Internally, it was referring to option value 0, not "FIFO" ... and that's the main reason why adding options usually is a pain in the ass.
When you import a text file, it's the same as creating a new object, writing all the text that exists in your text file into the object, and save it (not compile). Let's try to do the same as above and see what happens. So we'll start with table 27 Costing Method field without the extra option:
So, using text files, you avoid working with the internal integer values.
What else it is useful for:
You can apply the same method when you work with automation, and you want to install a new version. In my experience, when upgrading my WaldoNavPad, a bunch of code was changed (some function names/properties/... changed to other function names). I'm not a real .NET expert, and I don't know why this is. But as I always write my automation code in one or two codeunits, this is my workaround for it:
I would like to end with a few warnings:
IF myOptionField = myOptionField::"The Option Value" THEN ...
IF myOptionField = 1 THEN ...
Keep these warnings in mind. I still recommend for just adding the options at the end of the string. Definitally in a live system.
Hope it's useful!
Ps, When writing this blog, I found a thread on Mibuso that already covered this topic. You can find it here.
I wouldn't say - I still recommend for just adding the options at the end of the string.
The best way is to set it to the End plus about 10 commas.
The reason is very simple ... merging.
An extra remark for adding an option to an existing list of options:
Not just add it to the end, but add some , before it.
In general I start to use the 20th value for the next option. This way, you leave some space for future standard options.
If tomorrow MS decided to do this:
"FIFO,LIFO,Specific,Average,Standard,Some MS Value", you do not need to change the value of option "Waldo" in the database.
Also use this in the option-captions.
The beautiful thing is that the empty option-values are NOT shown between the possible option to choose from.
Yes that's correct. If you export an uncompiled object, then you only export the text. When you compile it you export both the executable object AND the text.
Thanks for sharing this, David.
It actually makes we wonder. If you save the object uncompiled ... and you export the object ... do you get the text file in stead of the fob file?
Yes Eric, very useful blog, I am sure it will help a lot of people.
Just to add to this, you can also do this in the normal C/SIDE editor without every having to export anything. Like this:
Find all the objects that have the Optin used.
Open the object, and start to save it.
At the prompt to save Yes/No de-select the object to compile.
(So save the object un-compiled)
Repeat for all objects.
Now go back to the tables with the Options.
Change the option string.
Repeat for all the required tables.
Now select all the objects that are un-compiled.
Since the objects were saved in text format, its just like using a text editor, in that the integer value is not used.
Hey, that's cool .
I wrote the article, but I was doubting to put it online. Glad I did though .
Hi Waldo, nice blog-article. I will refer future students to this when explaining when to use the fob and when to use the txt format for objects.
Microsoft Dynamics MCT