LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Closing references out of order?

I am filling a tree control from a Sub-VI, and I would like to use the DeferPanelUpdates property while I do that.  I would like to put the DeferPanelUpdates property node in the sub-vi so the main vi's block diagram isn't cluttered with it.  So since I already pass a reference to the tree control, I get it's OwningVI, and the FrontPanel from that.
 
The help for OwningVI says to close the reference to it when you're done using it.  But since I get the panel reference from it, do I have wait until I close the panel reference before closing the VI reference? I'm just not sure when I am "done" with the VI reference, if you know what i mean...
 
 
Also, do I need to wire all the error terminals on the property nodes? If the tree refnum is invalid, would OwningVI and thus FrontPanel also return invalid refnums? If that were the case, I could just check the last property node's error terminal.
 
Any ideas?
 
BTW, I found out about DeferPanelUpdates on one of Darren's Nuggets.  From there, there is a link to a thread about when to close references.  It didn't say anything about what to do about references obtained from other references though.
 
Thanks,
 
John
0 Kudos
Message 1 of 4
(2,488 Views)
Good question, John.  In your case, it is safe to close the VI reference at whatever time you wish.  In my experience *with VI Server* (these suggestions may not apply with other reference types, like ActiveX), if you get references as properties from other references, you can close them in whatever order you wish.  The only time it would be bad to close the VI reference first would be if you obtained it from an Open VI Reference function, and that was the only reference open to the VI.  If you close that reference to the VI, then there are no other references to it, and the VI is not in memory (assuming you don't have it open)...at that point, any subsequent property reads/writes would return an error.
 
As far as your question about error chaining, you should definitely wire the errors...there are many reasons you could get errors from property nodes...invalid references, trying to set some properties while the VI is running, certain properties that don't work with objects configured a certain way...don't ever skimp on your error handling, *especially* with VI Server!
 
When I work with VI Server and a bunch of different class properties, I find it helps to keep my error chain straight, and route reference wires accordingly.  It helps me keep with the program flow better...here's how I would have wired the diagram you gave above:
 
 
Hope this helps, and I'm glad you discovered my nugget about Defer Panel Updates.  When doing code reviews of UI applications, that is probably the recommendation I've given the most times over the years...
 
-D

Message Edited by Darren on 01-23-2007 10:31 PM

Message 2 of 4
(2,472 Views)
Thanks Darren!  It does make it easier to see what's going on with the property nodes lined up.  I played with that for a while, and came up with the stairsteps so that I could wire all the references across the diagram nicely.  But with just one reference going around the structure, it makes things easier. 😄
 
I ended up wiring the tree reference through the property node though, just because it makes me feel better.  I don't see any reason that reading the OwningVI property could have any effect on the tree or its reference, but whatever... or maybe.. is that ever possible? That reading a property will modify the reference (in general, not just for a tree control)?
 
John
0 Kudos
Message 3 of 4
(2,461 Views)
Reading a property should never modify a reference.  When you've got a property node or invoke node, the reference is always a pass-through,  i.e. the reference output is always the same as the reference input.  Even if the property node returns an error, the reference output is still valid (since it's just a pass-through).
 
-D
0 Kudos
Message 4 of 4
(2,449 Views)