NI_LVConfig.lvlib Refnum Question

[SteveChandler]

I was just looking at the NI_LVConfig.lvlib code (LabVIEW 2011) to see how it is implemented. There are a lot of cool techniques to learn in that module.

Internally it uses a queue to pass information. The queue refnum gets cast to a datalog refnum which is used to connect the public API. The datalog structure refnum is defined as a single item enum.

As far as I can tell the module does not even use datalog files. It just uses text files.

Can anyone explain what the heck they are doing? Why convert the queue reference to a datalog reference and back again? Is this some kind of backward compatibility trick? The oldest version of LabVIEW I have available is 2010.

[Ben]

Compatiblility is one factor I suspect (only Stephan and his crew know WHY ).

In the earliest version of the cfg file functions (that I am aware of) the code constructs used in the OLD GOOP tookit (the one that used a core that could not be touched! I think it was Edevo ... ). Each data type had a core containing that data type as a 2d (?) array. If memory serves me the file ref helped select the element of the array (going on memory remeber!) since a single core was used for all instances of the config functions. When you read/wrote data you read/wrote elements of the array. So the ref for config files where an index (if I remeber correctly). THey were cast as datalog types so they looked like file refs.

The files themsleves were always record based strings. Using the datalog type wire prevented stirng file I/O functions from being used inappropriately on the files forcing you to use the code Stephan wrote.

THey were eventually converted to queues and latter realised as LVOOP in a library.

So the real reason lies in the old GOOP toolkit. I never overcame the learning curve required to use GOOP so most of what I have said above is highly questionable.

I would like to hear or read a white paper on Stephans experiences with how he has adapted this very useful set of functions over the ages as he has harnessed new technolgy to enhance the functionality and performance almost flawlessly through all of the versions. 

Edit:

It was a GOOP reason I do not reacall. Let's see if we can invoke more info

GOOP GOOP GOOP Endevo Endevo Endevo

Ben

[tst]

To add to what Ben said, what you're looking at is a new version of the toolkit, created in LV 2009. It uses the refnum to maintain compatibility with the old version, since there may be a lot of programs around which use the refnums.

The reason for using the refnum in the first place is probably that when it was originally created, using a data log refnum was probably the only easy way you had to create your own custom reference in G. Even today, if you look at the palettes, you will see that the refnum control itself is empty, waiting for you to put something in it. Using a typedef enum ensured that this wire type will be unique and break if you wire it into anything else.

As for what happens inside, the single element queue is basically used to hold all the data of the files. Today, you might as well just use LVOOP and a DVR instead of the datalog refnum, since it provides the same functionality and is easier to understand (at least the DVR is).

[SteveChandler]

I suppose the stuff in vi.lib is not the best place to learn modern programming practices, although learning old techniques is helpful for when old code is inherited.

Thanks for the replies!