Leaderboard

Jim Kring wrote: Strong recommendation we've developed over the last few years: If your object contains even a single refnum, make the wire color be refnum green. I even updated the color picker in LabVIEW 2009 so that refnum green is one of the default colors displayed so it is easy to grab it for your wire designs (it's the last non-gray square in the row of pre-selected colors). Also, I've had a few people suggest that if one member of your private data control is a refnum then all of them should be refnums, so that everything in the object behaves like a reference. I'm not sure what I think of that, but I'll throw it out there for consideration. Unfortunately, the bookkeeping on this is significantly problematic. Essentially, you'd need the inside of the IPE to output an array of refnums that are "the refnums I currently have deref'd" and then pass that by dataflow to any nested (including inside subVIs) IPEs. But the subVIs don't have magic secret inputs/outputs that would allow this information to pass along, and trying to do it in a "global store that each IPE checks to see if refnum was used upstream" requires the IPE to know aspects of dataflow that are simply unknowable, such as what nodes are upstream of it. We did kick around embedding the information in the refnum wire itself, but with a reference, there's no guarantee that the reference is used in only one place.In the end, we couldn't find a way for the IPE to tell the difference between a refnum that was dereferenced upstream (and should error) and dereferenced in parallel (that will eventually be released), except in the most trivial of cases. If you're writing circular reference code, you'll need to carry along with the refnum a parallel array of refnums already opened, and at every IPE, manually check whether the chosen refnum is already referenced.

Cheers, but its not that I want to load it, I just want to know when the VI tests itself - is it the "active VI" in the subpanel out of a possible number of VIs at a given time. So if it isn't I don't want any actions to be performed, so unfortunately this will not work for my task. Thanks tho. <edit> Ok had a thought and it worked The Front Panel:Open property is True when the VI is loaded in the subpanel False otherwise Easy! Problem sorted Cheers </edit>

If you haven't tried this already... Click on your name in the upper right-hand corner Select "My Settings" Select "General Settings" (should be the default) Down at the bottom of the page under "Search Settings" -> "View New Content Method" Select "Show me all the content I have not read"

Here's some info on the post build hook. http://forums.jkisoft.com/index.php?showtopic=839 I don't know if there is similar hooks for post install. I didn't know that VIPM supported post install hooks, are you sure you mean post install? Remember that the post build VI does not get brought to the front, or focused when it is ran, so if there is some user interaction you'll need to use a Windows DLL to bring it into focus.

Excellent "cat skinning" there Shaun! You absolutely shreaded the "box" I was thinking in. Ben

Not sure if there is a better way. But if you try to load it into a sub-panel and it is already in one, you will get Error 1145 Possible Reason(s) Labview: Cannot open VI because it is already in a subpanel control. If its not in memory, it will succeed, and if its already running but not in a sub panel you get Error 1144 LAbview: Cannot insert VI in subpanel because VI is already open.

I checked the source code of the OGPB and the pre and post-build VIs don't get any parameters. I think it is quite save to say that nothing is sent in the other VIs. Checking the pre- and post - install VIs should be done with the source code of OpenG commander. However I think that VIPM tries to read the 'error in' and 'error out' controls if they are available. Ton