06-01-2015 04:42 PM
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.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
06-01-2015 04:54 PM
@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?
06-01-2015 05:05 PM - edited 06-01-2015 05:12 PM
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.
06-01-2015 05:11 PM
@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
06-01-2015 05:12 PM
@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.
06-02-2015 12:22 AM
@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.
06-02-2015 01:23 AM
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.
06-02-2015 06:58 AM
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.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord