LabVIEW Class Private Data issue

[Bhargavi_1]

Hi all,

I am facing an issue with the private data of the class.

I am using an object in the "X.vi". This works fine when I am developing the code.

I have built the package of developed code, along with this added "X.vi" to the palette.

Now, when I drop the "X.vi" from the palette the VI is broken and the error is "Private data control of this class is not a valid data type."

But When I open the same "X.vi" from vi.lib, the VI is not broken.

I am not sure what is happening at the background. Can anyone help me in understanding and solving this issue.

Thanks in advance,

Bhargavi Gowri.

[wiebe@CARYA]

Opening a VI and dropping it in another is different.

Opening will not cause an error if for instance the VI is a private class member, or if there are required connector pane terminals. Dropping the VI could cause an error where you drop it...

Those situations will not give the error you've given. As an experiment, what happens when you open the VI and then drop it manually in a new VI?

What happens when you drop the VI from the palette, and then open it?

Does the VI have an input\output type def control that is private?

[Bhargavi_1]

Hi wiebe@CARYA,

Thanks for the reply

I am aware that the new VI will be broken when I drop any VI which has required terminals. Sorry if I was not able to explain it better.

The issue that I was explaining was

When I drop "X.vi" into a new VI and open the "X.vi" by double-clicking the icon of "X.vi", I can see the error.

When I open "X.vi" from the file location, it will not show any error.

Hope I have given a clear explanation

Coming to the question "Does the VI have an input\output typedef control that is private?"

- The VI has typedefs, but they are not private. They are public typedefs. 

[paul.r]

Is the problem only with this single VI? Or any VI that uses that class? Is the VI a member of the class, or just uses the class?

[Bhargu]

Hi Paul,

This VI is a member of the class. I see this problem only with the two VIs of the class. Other VIs are working fine.

Thanks,

Bhargavi Gowri.

[wiebe@CARYA]

That is weird. I doubt there is a legit reason for this behavior.

Sounds like the VI dropped from the palette opens the VI in a different context.

Is this done from a class that is in memory? For instance from a project the class is in?

What happens with the broken VI when you load the class?

What happens when you save the new VI, close it, then load it?

[paul.r]

---

wiebe@CARYA wrote:

That is weird. I doubt there is a legit reason for this behavior.

---

Agreed - have you tried mass compiling the source and rebuilding the package?

[Bhargavi_1]

Hi wiebe@CARYA,

When I load the project and open the VI from the project, it looks good(No broken wire).

The issue is not seen, when I save the new VI, close it and load it again.

Not sure how it is getting solved

So, what makes it different when I load from the palette? Is there anything that I can achieve by changing the name of the VI?

Thanks for the reply

[Bhargavi_1]

Hi Paul,

This doesn't solve the problem 😞

Anyways Thanks

[wiebe@CARYA]

I'm getting a feeling that NI should change something.

When dropping from the palette, the class doesn't seem to be loaded (properly). When closing the VI and opening it again, the normal procedure is executed, and the class is loaded. When working with a project, and the class is in the project, the class is already loaded. So it can work as expected.

Some other things might make it work. After dropping, delete the node and then undo. That might trigger the class load. Or save, make a change, and then revert.

I'd guess that once the VI is working normally, dropping from the palette works as well, as the class is already in memory?