Objects and Call by Ref node "ILLEGAL?!?"

[Norm Kirchner]

So even though LVoop objects are by value, word around the block has it that you are not supposed to be able to pass objects across application references.

Let me give you a for instance why this is gonna suck.

You build a master slave application in which the master resides on a local PC and the slave on a remote PC.

If you build any code structure build off of LVoop then you're hosed (although not totally)when you want to send information back and forth.

BULL$H!t

</rant>

<solution>

If LVoop is by value and has version numbers along with it, then the value stored in the wire should be flattened as is and passed to anyone else just like if it were a string by value.

questions, comments?

[Tomi Maila]

As far as I know you can pass objects across application instances and what happens behind the scenes when you do is that LabVIEW flattenes the object to string and then unflattenes it on the other end. I've not veirified that this works. You should also be able to manually flatten an object to string and unflatten it froms string.

I didn't really understand you point. Can you please be more specific. Some code would be nice and informative.

[Norm Kirchner]

QUOTE(Tomi Maila @ Apr 17 2007, 11:49 AM)

As far as I know you can pass objects across application instances and what happens behind the scenes when you do is that LabVIEW flattenes the object to string and then unflattenes it on the other end. I've not veirified that this works. You should also be able to manually flatten an object to string and unflatten it froms string.

I didn't really understand you point. Can you please be more specific. Some code would be nice and informative.

No, you understood correctly.

This is what you would expect, but I heard from the horses mouth that this is not supposed to be legal although that if you use TCP/IP that you can make it happen but you get some errors when you return the object.

http://forums.lavag.org/index.php?act=attach&type=post&id=5539''>http://forums.lavag.org/index.php?act=attach&type=post&id=5539'>http://forums.lavag.org/index.php?act=attach&type=post&id=5539

If you do this, and the object inputs are not dynamic, I have seen it work, it's not supposed to, but if you open the ref w/ TCP it will. So who knows what kind of quirky things will happen or if they will cut it off all together.

[Tomi Maila]

Aristos Queue, could you please confirm if the code in the above image should work when a an application reference is remote and the VI reference is of

1. normal VIs that do not belong to LVClass
   
2. static method VI (non dynamic-dispatch)
   
3. dynamic dispatch VI and dynamic dispatching is actually needed to decide the actual method to call
   

If any of those do not work, I'd appreciate a proposal for a workaround. If for example the 3. case do not work as the location of descendant classes cannot be known by the time of call, can we just place all possible class constant on the block diagram of the VI or something similar.

Tomi

[Norm Kirchner]

QUOTE(Tomi Maila @ Apr 17 2007, 01:57 PM)

....can we just place all possible class constant on the block diagram of the VI or something similar.

Tomi

Just for reference, if you plan to do dynamic calls w/ built exe, you need to have contstants of all objects to be used present anyways, somewhere in the non-dynamic code due to difficulties building w/ objects and managing exclusions and inclusions

I've just run around the track a few times on this one and have figured out w/ the help of the good folk @ NI how to do this.

[Aristos Queue]

The LV shipping documentation covers this in more detail. Long and short of it ... when you open your application reference, wire a port number to the Open App Reference node. This should make the CBR work. The logic behind this is something we can discuss some other day.