Bug in Write Key (Variant)__ogtk.vi

[GuyFromCanada]

I came across a bug/omission, perhaps in the update to 64bit.

C:\Program Files\National Instruments\LabVIEW 2017\user.lib\_OpenG.lib\variantconfig\variantconfig.llb\Write Key (Variant)__ogtk.vi

If you go to the case structure, the 64 bit datatypes (I64, U64, Enum U64, etc.) are missing. The result is that the default case is used and that parses the result incorrectly. It can be fixed by adding the 64 bit datatypes to the case structure.

[Rolf Kalbermatter]

On 7/19/2018 at 6:07 PM, GuyFromCanada said:

I came across a bug/omission, perhaps in the update to 64bit.

C:\Program Files\National Instruments\LabVIEW 2017\user.lib\_OpenG.lib\variantconfig\variantconfig.llb\Write Key (Variant)__ogtk.vi

If you go to the case structure, the 64 bit datatypes (I64, U64, Enum U64, etc.) are missing. The result is that the default case is used and that parses the result incorrectly. It can be fixed by adding the 64 bit datatypes to the case structure.

When this library was created somewhere around 2000 or so, LabVIEW was still more than 5 years away from supporting 64 bit integers in any way. So it could not be added then even if one had wanted to. And the OpenG movement has lost a bit of traction in the last 15 years or so. Nobody seems to have noticed this deficit or if they did they just added the extra cases without reporting it back.

The real problem is however that these libraries, while not perfect, do work for most users good enough to not bother about putting the effort into it to update them and the original maintainers for each of those libraries almost all moved into other positions that often mean less or now daily LabVIEW programming anymore. The OpenG libraries also follow a development model that makes it difficult to push updates by other users into it and release a new version.

But the according Read Key VI also has that omission, only here the fix is more complicated to perform since the VI uses the NI INI file class which still only supports 32 bit integers. So at least for the 64 bit variant something else needs to be developed and in doing so it probably would be best to change the other integer types too to use the same method.

Edited July 31, 2018 by rolfk