Obtain Class default type from variant

[UnlikelyNomad]

I'm receiving a class instance in a variant that I'm trying to enumerate types contained for. The attached screenie works great when run normally but it's being executed in a different context and the get class default from name is returning an error.

1. Is there a way to access other contexts via VI Server?

2. Is there a simpler way to get the private data control cluster default value?

[hooovahh]

You say it is being ran in a different context, can you provide the context that it needs to be ran in?  I'm having a hard thinking of a way to test this.  Are you saying you have one EXE running, that the variant data is being passed to from another?  Still I would expect the code to work properly since the LVClass.Open is providing the full path to the class.  Is it possible the error is coming from some other place?  Does this class not have a front panel in its private data?  I admit I don't know what happens to classes once they are put into an EXE and would wonder if that is stripped out.

Edit:  Oh the get class by name will only work if that class is in memory.  Just like referencing a VI by name only works if the VI is in memory.  If you are loading from a separate context it won't be in memory.  You need to provide the path to the Get LV Class Default Value and have it return the class.  Then the rest should work (maybe)

[smithd]

Given your other post is it safe to assume this is an xnode?

 

In that case, maybe you can use this https://lavag.org/topic/19781-xnode-owning-diagram/ to get a ref to the VI you're dropping on and then use that vi ref to get the application context and from there go crazy with property nodes across application contexts?

[DTaylor]

14 hours ago, smithd said:

In that case, maybe you can use this https://lavag.org/topic/19781-xnode-owning-diagram/ to get a ref to the VI you're dropping on and then use that vi ref to get the application context and from there go crazy with property nodes across application contexts?

This works, but I think he'll also have to put Get LV Class Default Value by Name and Get LV Class Path into a SubVI - let's call it Get LV Class Path by Name. He'll then have to open a reference to that VI with the appropriate application reference and do a call by reference. Then he can go crazy with property nodes across application contexts.

[DTaylor]

Like this:

SubVI Contents:

[UnlikelyNomad]

Yes, XNode heh.

Thanks smithd and DT, I'm going to work on those and give it a shot!

I don't need to open the subvi in the context, I can just use open VI, take the Results.lvclass from the variant, add ":Results.ctl" and open it using the OwningVI's OwningApp property!

Thanks for the push. I had tried to find something about getting the other app context but glanced right by it and missed it.

[UnlikelyNomad]

So I definitely need to do some refactoring of my menu generation code to hide the extra intermediate elements but now I can use it for what I was intending!

[UnlikelyNomad]

And here is what the relevant bit of "solved" code looks like. The VI.OwningApp property was the key that I had glanced over and allows opening items from memory by name from the project, which aren't available from the NI.LV.XNode context.

[Aristos Queue]

Classes on the terminals of XNodes are somewhat unstable and crashy. The key way to avoid a crash is to put a "Request Deallocation" primitive wired with a constant TRUE on the block diagram of every VI that has a variant that could contain a LabVIEW class. But you then also have to be careful not to use your XNode in two separate user contexts at the same time unless the class is defined identically in both user contexts.

The two features were never designed to work with each other (they came into existence at the same time and weren't really aware of what the other's needs would be). One or the other would have to be completely redesigned to accommodate the other. There are some safe paths, but I can't give much guidance there... I have to derive them special for every XNode I work on... which is why I rarely use XNodes. YMMV.

But, seriously... add the Request Deallocation nodes. You'll save yourself a lot of pain.