LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Create VI Reference from VI Reference

Given a VI reference that is valid, is there an easier way to create a new VI reference, other than by using a property node, pulling the VI name, and using Open VI reference?

 

I've never needed to do this before but I assumed there would be some invoke node that made a new reference pointing to the same object but couldn't find one.

0 Kudos
Message 1 of 8
(2,990 Views)

@Hooovahh wrote:

Given a VI reference that is valid, is there an easier way to create a new VI reference, other than by using a property node, pulling the VI name, and using Open VI reference?

 

I've never needed to do this before but I assumed there would be some invoke node that made a new reference pointing to the same object but couldn't find one.


OK, I'm a bit confussed.  You have a valid reference and want a second reference to the same object?  I can't really see the use case but,  Branch the wire and use an Always Copy should give you two pointers to the same object right?


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 8
(2,977 Views)

I'm presuming you want to be able to duplicate the reference so that if the current one is closed (which may be beyond your control) the VI is not disposed of, right?

 

The only method I see at the moment is via VI.Name.  All others copy the VALUE of the reference but will not prevent a VI being aborted if the original reference is destroyed.  It hink the "Open" primitive is instrumental in this.

Message 3 of 8
(2,970 Views)

@Intaris wrote:

I'm presuming you want to be able to duplicate the reference so that if the current one is closed (which may be beyond your control) the VI is not disposed of, right?


That would be a use case I had never thought of


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 8
(2,961 Views)

@JÞB wrote:

@Intaris wrote:

I'm presuming you want to be able to duplicate the reference so that if the current one is closed (which may be beyond your control) the VI is not disposed of, right?


That would be a use case I had never thought of


Having being burned using Subpanels in the past (Requiring FP.Close to be called before inserting), it's a use-case I'll never forget.

Message 5 of 8
(2,958 Views)

@Hooovahh wrote:

 

I've never needed to do this before but I assumed there would be some invoke node that made a new reference pointing to the same object


From an API design prespective, what made you think that? This isn't something I would expect to find to in an API, as there are specific functions for obtaining references.


___________________
Try to take over the world!
0 Kudos
Message 6 of 8
(2,918 Views)

Hooovahh wrote:

 

I've never needed to do this before but I assumed there would be some invoke node that made a new reference pointing to the same object but couldn't find one.


That would be equivalent to the Java clone() method, something many agree to have been a pretty bad idea. Actually it's not so much the idea itself that is bad but the complications that arise from implementing a proper working clone() method. So complicated in fact that most programmers get it wrong at some point and the resulting object is then broken by design when anyone is using the clone() method.

 

Read any Java programming manual and you will usually read a big warning to avoid clone() at almost any cost.

Rolf Kalbermatter
My Blog
Message 7 of 8
(2,903 Views)

Glad to wake up to several good responses.  Yes this is using an API where the lifetime of the VI reference cannot be guaranteed, but at the same time I want to be able to shove the reference somewhere for possible future use.  So I need to make my own reference that I can have control of which points to the same VI.

 

I officially started my programming career with Java so maybe that is where I remember hearing about this idea.  Maybe I'll make a reuse VI that does this form me, using the VI name and Open Reference I mentioned in the first post.

0 Kudos
Message 8 of 8
(2,859 Views)