Is Help Context for "LabVIEW Class:Open Method" Correct?

[DamienGaudry]

I'm working on something similar to the code discussed in this thread.

https://forums.ni.com/t5/LabVIEW/Getting-Packed-Project-Library-Build-Number/td-p/3221823

The solution discussed in the thread above returns the file version of a PPL (as created by the build specification that created the PPL) from a VI within the PPL.  I wanted to build on that solution to return the file version of a PPL based on a class contained within that PPL.  See the code below for implementation:

The code works as intended, however, after reviewing the help for the invoke/property nodes used, I noticed that "LVClass.Open" and "Private Data Control" indicate that they are not "Available in Run-Time Engine".

Based on my tests, this doesn't appear to be accurate, as I have build this code into a PPL and called that PPL from an EXE without error (I've also had no problem calling this code from TestStand with the LabVIEW adapter configured to use the Run-Time Engine).  I'm using LabVIEW 2016, is the Help just out of date or should I expect this functionality to go away in the future?

Thanks,

Damien

[AirFrantz]

I guess if it works it works!  But joking aside I'm interested if there is a reason why it works in this particular case.  If you run this on a machine that does not have the LabVIEW development environment does it still work correctly?

[wiebe@CARYA]

The used method LVCLass.open is marked not available in RTE (at least in LV2013). It does work in RTE however. I'd say the RTE availability of this VI is based on the RTE availability of that method.

BTW. That method is annoying in dev.env. though, as it changes the cursor to buzzy state. This can really kill the user experience if it's used during normal operation. I usually get a class from the project during development, and from LVCLass.open in RTE using a conditional disabled structure.

[DamienGaudry]

Hello wiebe@CARYA,

Thanks for confirming that you see the same behavior in a different version of LabVIEW.  I'm going to assume the help is wrong.

Jon,

I don't have access to a machine without LabVIEW to run further tests.  How do we proceed to confirm the help is wrong and get it corrected for future versions of LabVIEW?

Damien

[wiebe@CARYA]

---

@DamienGaudry wrote:

Jon,

I don't have access to a machine without LabVIEW to run further tests.  How do we proceed to confirm the help is wrong and get it corrected for future versions of LabVIEW?

---

I don't see how that would make a difference. The RTE should not, and in my experience is not, in any way related to the dev.env.. (Apart from sharing of drivers and such. And a VI could of course open an app reference to the dev.env.).

[DamienGaudry]

I agree (that was my polite way of saying that test is not going to add any value)

How do we proceed to get the documentation updated?

[wiebe@CARYA]

I usually hope someone will file a CAR. I know there is an official way to do this, but I keep forgetting as I don't do it that often.

[AirFrantz]

The best way to get a CAR filed is to create a Service Request in the Service Request Manager at ni.com/support.  'Bug Report' should be one of the options for request type.  Then an Applications Engineer can review the behavior and file an official CAR.  I would encourage you to go through this process.

[wiebe@CARYA]

And don't forget to point to this thread. In fact, you can probably just point to this thread and leave it at that.