Variant to class-data context dependend error

[Jeffrey Habets]

Hi All,

While writing a RCF plugin I bumped into this problem which I was also able to reproduce outside of the RCF framework, so it's probably not a framework issue.

The piece of code shown tests a diagram's selection list for class wires and returns the wire ref and class path of the first class-wire found. This code works whenever the VI that it's operating on is in the main application context. When I have opened the same VI from within it's project, the variant to data function returns error code 91 (The data type of the variant is not compatible with the data type wired to the type input). However the datatype in the variant is under both circumstances exactly the same.

Also, after the error 91, LV becomes instable. Doing edits in my script-VI or even just saving it gives me an fpsane crash on line 432.

Your thoughts please? Am I looking at a bug here?

Jeffrey

[jgcode]

Hi All,

While writing a RCF plugin I bumped into this problem which I was also able to reproduce outside of the RCF framework, so it's probably not a framework issue.

The piece of code shown tests a diagram's selection list for class wires and returns the wire ref and class path of the first class-wire found. This code works whenever the VI that it's operating on is in the main application context. When I have opened the same VI from within it's project, the variant to data function returns error code 91 (The data type of the variant is not compatible with the data type wired to the type input). However the datatype in the variant is under both circumstances exactly the same.

Also, after the error 91, LV becomes instable. Doing edits in my script-VI or even just saving it gives me an fpsane crash on line 432.

Your thoughts please? Am I looking at a bug here?

Jeffrey

Hi Jeffery

I don't know if its a bug?

But I ran into the exact same problem using the property node Data Value of a Class with either Get LV Class Path.vi or Get LV Class Default Value.vi and RCF - it ran fine in LV but not the application context of RCF.

All I wanted to do was find the Class Control's Class Name

So I typecasted the selected GOObject/Control reference to a Class, got the data value, wired that to the Get LV Class Path.vi, to parse the class name or something like that (I can't remember exactly).

But there was a much easier way: All I had to do was get the Library Reference from the VI property node (RCF was acting on a Class Data Member VI). Then get the class name!!

Depending on what you are trying to do there may be an another way i.e. if you just require a Library Ref to the class.

What are you trying to do?

Edited September 14, 2009 by jgcode

[Aristos Queue]

Your thoughts please? :blink:Am I looking at a bug here?

A bug? Only sort of. Yes, it's abug, yes it makes LV unstable, but, um... no, it is unlikely to befixed.

This is documented somewhere but I can't find it at the moment. If Iload A.lvclass in AppInstance 1, that same piece of data cannot be usedin AppInstance 2 because

1. if we close AppInstance 1, the class leaves memory, which wouldleave the data in AppInstance 2 without a class definition which wouldcause LV to crash the next time you copy, delete or access that data.(in fact, this crash is what's bringing down your VI, but we'll get tothat in a moment)
2. and because the A.lvclass loaded in AppInstance 1 might not bethe same as the A.lvclass loaded in AppInstance 2. One might bec:\A.lvclass and the other might be d:\A.lvclass, and they might nothave anywhere close to the same definition. Applying the assemblyinstructions to copy one an object of the first class might createcompletely corrupt objects if applied to objects of the other class.

The only correct way to shuffle object data from AppInstance 1 toAppInstance 2 is to flatten it to string and unflatten it from string.This happens automatically when the two AppInstances are on differentmachines -- the objects are flattened to go across the network. Thishappens automatically if the wire type is LVClass and not variant, evenwhen the two AppInstances are on the same computer. And it happensautomatically for variants when the two AppInstances are on the samecomputer if you wire a port number to the Open Application Instanceprimitive.

However, it does not happen automatically when you're using varianttype to transfer the class data and the contexts are on the samemachine and you didn't specify a port number for the Open App Reference. Why doesn't it happen automatically? Because LV would have to flatten and then unflatten every variant as it crossed the context boundaries on the off chance that there's a class buried somewhere inside -- in the data, in an attribute, in a cluster of array of cluster of variant's attribute, etc. When I put that code into LV, performance of many many apps went way way way down. It seems that many scripting functions, editor extensions, etc, grab data across the boundaries. That's a real problem for LV classes, but I've got no way to detect it (even just testing for the data type at runtime was too much of a performance hit).

As I said, this is documented in the shipping docs somewhere, and I know I've typed this up before.

[Jeffrey Habets]

What are you trying to do?

What I'm trying to do is get a list of all class methods of the selected wire.. I'll populate the right-click menu with this list so the user can do a quick drop or insert of a method of the specific class without having to browse or going to the project.

A bug? Only sort of. Yes, it's abug, yes it makes LV unstable, but, um... no, it is unlikely to befixed.

This is documented somewhere but I can't find it at the moment. If Iload A.lvclass in AppInstance 1, that same piece of data cannot be usedin AppInstance 2 because

...

As I said, this is documented in the shipping docs somewhere, and I know I've typed this up before.

If it's documented, it's very well hidden.. I wasn't able to find it either.

Anyway, thanks for the insight, it was very helpfull.

I now simply run the sub-vi containing the pictured code via a call-by-ref in the application context of the VI it's operating on and just return the class-path and wire ref.

Jeffrey