LabVIEW
Path for Config Refnum?
@tst wrote:
Those work, but it should be pointed out that they rely on the internal implementation of the library, and this will stop working if that ever changes (which can happen). I would not recommend using this in any code you have to support long term.
I'm actually a bit surprised that NI used a library for this instead of a class, because if part of the point of refactoring was to protect the internals of the code from people playing with them directly, then they failed to do that, as you just demonstrated.
I agree with the warning. It accesses private data that can change at any time. Basically it's a workaround for the change of the config VIs to be part of a lvlib but that workaround would for instance just as much fail if they changed the names of elements in the cluster.
I would suppose the main reason is using lvlib instead of lvclass for the new implementation are twofold. One is that the config file refnum would be a class wire and that could break existing software when upgraded to the new LabVIEW version, unless they find a way to intelligently recognize all config file refnum controls in the existing application and mutate them too. There are quite a few possibilities where this is almost impossible without breaking something.
The other is that it is much less effort to wrap all the existing VIs in an lvlib than to port them to a proper lvclass.
