Lazy Programming: What text-based object files are good for

Waldo

Source: my blog

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:

In table 27 (Item), we all know the Option Field: Costing Method with the Option String: FIFO,LIFO,Specific,Average,Standard.
Let's create a new codeunit with this code (and save and compile):

IF lrecItem."Costing Method" = lrecItem."Costing Method"::"FIFO" THEN;

Now, let's add an option value to that field so that the Option String becomes: waldo,FIFO,LIFO,Specific,Average,Standard
Just open your codeunit again and you'll see your line of code has changed to:

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:

Export table 27 and your codeunit to a text file.
Open the text file and replace "FIFO,LIFO,Specific,Average,Standard" by "waldo,FIFO,LIFO,Specific,Average,Standard". (You'll have to do this for all translations as well ... ).
Save the text file and import in NAV.
If you check the table and field, you'll see the options has been added. If you check the codeunit, you'll see the code is still correct!
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:

Export the codeunit(s) to text
Install the new version of the NavPad
Import the codeunit(s) and compile
I would like to end with a few warnings:
* Be sure you export all objects where the options are used. This is rather easy for customizations, but quite difficult for standard option fields. For this, I recommend using the Developer's Toolkit or just export all objects .
* This solution will only work when you use options in code like:

IF myOptionField = myOptionField::"The Option Value" THEN ...

And not:

IF myOptionField = 1 THEN ...

* Mind the translations.
* Update your data. (the values won't be updated when changing your objects, off course). This can have a huge impact, because one option field is usually used (copied) in multiple tables. You have to update your live system.

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.

Luc_VanDyck

Waldo wrote:

Ps, When writing this blog, I found a thread on Mibuso that already covered this topic. You can find it here.

Thank you for your detailed post!
And now you know why the slogan of mibuso.com is "Your favourite knowledge base" ;-)

DenSter

Very interesting that it works that way.

It's never been difficult to do this though, from a technical development standpoint, this has always been a relatively easy task to do. It's the data aspect that causes this to be an almost impossible task, because you just can't guarantee complete success.

I am still dead set against putting option values into the existing list though, at least for standard NAV fields, that just comes with too much problems. For your own custom stuff this is OK because you have control over it, but with standard NAV objects you have to add a whole bunch of commas and then the new values, so that would turn into "FIFO,LIFO,Specific,Average,Standard,,,,,,,,,,waldo" instead of "waldo,FIFO,LIFO,Specific,Average,Standard".

kriki

If "waldo,FIFO,LIFO,Specific,Average,Standard" is needed, it might be a good idea to create a new field in the table with the options in this order and putting this field in the form for the user to change it, the OnValidate-trigger changes the original field with the new option behind the other options.
In this way the user is happy because he has his new option somewhere in the middle and we are happy because the new option is at the end.

Belias

I'm wondering if this works with field renaming, too...why?
I'm upgrading from 40 to 501, and one of the personalizations added field 50000, "e-mail", in 40 version.
obviously :evil: nav 501 introduced a new field "e-mail", so i have to rename one of the two...
then, all the code in the std objects will refer to the std field, and all the personalized objects will refer to the personalized field...i hope it will work, if not so, i'll disable the field and recompile everything...i'll let you know!

Belias

no, it doesn't work