Open VI reference without refees

[SteenSchmidt]

Hi,

I suggest an option added to the Open VI Reference primitive to open that VI reference without any refees. I suggest option bit 10, i.e. option 0x200h:

The demand for this arises when you want to access methods and properties of VIs that may be broken, while on the other hand you don't have any need to run those VIs - for instance in one of my current tools (BatchEditor) where I'm tasked with investigating hundreds of VIs simultaneously of which some could be broken or missing dependencies. Other situations would be tools for traversing project trees for instance. Opening a large number of healthy VI references takes a while, and when something is broken in a VI, opening even a single reference could take 30 seconds to minutes.

Currently you can suppress the "loading" and "searching" dialogs by setting option 0x20h on the Open VI Reference primitive, but that only loads the refnum silently as far as that will get you. Opening the refnum takes the same amount of time as if you could see those dialogs, and you are rewarded with an explorer window if a dependency search fails. I just want a way to open a VI refnum without even starting to look for dependencies, thus very quickly and guaranteed silently.

The relevant people would know that this request isn't that hard to implement, as it is kind of already possibly using some ninja tricks. I'd like such an option to be public.

Cheers,

Steen

[JackDunaway]

"Making up words is also bad" I'll give you that; yet the word "Refee" encapsulates hard-to-describe semantics and is the established function name; I still contend it's an important keyword in a noisy forum, more likely to perk the ears of those whose ears we wish to perk. As soon as this feature is marked "In Development", i agree we could consider renaming from the fictional word 'refee'.

[Darin.K]

I do not see the need to beat around this particular bush.  Posting the actual method here is bad mojo since someone could start using it without understanding the many, many caveats.

Suffice it to say, a private method exists to open a VI reference without loading any of the external dependencies.  It is called Open.VI with Refees.  We would like that method to become public.

"Refees" is a side issue, jargon chosen by a developer to squeeze into the Invoke Node of a private method does not quite elevate it to the LV lexicon, yet.  The target audience is not a few NI folks who get the inside joke, but rather to succintly explain the goal of the operation to the masses and convince them that they may want to do the same.

The current picture does not really do justice to the proposed operation, I would probably have added a screenshot of the loading dialog we are all far too familiar with, and add a big X through it.

[SteenSchmidt]

@Jeff: My referral to ninja tricks was just private methods, i.e. that what I request is already possible but hidden from most people. I have no intention of doing stuff to LabVIEW objects and files that doesn't make sense. If I was to change a lib member I'd do my utmost to have the lib in the loop as well - anything else would just be crossing the stream to get water, and I'd consider that a serious bug in my code.

But I need this functionality for a batch editor I'm making. A tool that lets me point at a folder, a project, a VI, or memory, and then load all LabVIEW files at that location. Optionally vi.lib and other groups of dependencies can be loaded with the selected files or not. When loaded you can then do stuff to those files, for instance check/update against a style guide, set icon template, enable debugging, set passwords, remove blocks diagrams etc - all on single files or on multiple files at once. Therefore I need to be able to peek at many VIs/CTRLs/whatever through their VI Server refnums without being forced to load every and all dependency and library/class link. I need to control which files are loaded and which aren't.

/Steen

[warren_scott]

a key part to this is also being able to find out where LV thought all the dependencies were that would have been opened.  Right now the amount of information available for a SubVI / custom control / etc that is not found when the VI is opened is very limited.  We need to make sure that I can still traverse the block diagram and find all the SubVI's (that happen to not be loaded) and learn where LV WOULD HAVE loaded them from (including LVLIB information, because that is important too), and be able to change them to point to a different subVI.

[JackDunaway]

---

@SteenSchmidt wrote:

I agree Jack, and must admit that I was the pushover here - I requested the title change. I like refee much better though, as that is also what NI calls it in their own APIs. But when Bill and Jeff has no idea what we are on about, I thought that maybe many others won't either. Others who might benefit from this idea and otherwise would've voted for it.

Anyways, can we agree upon getting the idea title changed back the way it was, and then roll up our sleeves and explain to those who ask what it means?

---

I speak for myself; the title "Open VI reference without external ties" is a skimmer since first reaction to this is WAT?; reading the title "Open VI Without Refees", I couldn't find the Kudos button fast enough.

I wish there was a known formula to follow to increase the likelihood of important but esoteric ideas like this getting implemented; but the one I would tend to follow is try to appeal to R&D and toolmakers rather than the LabVIEW developer. Even though only 40 toolmakers and LAVAG'ers may ever vote for this idea, the benefit could be passed to orders of magnitude more LV devs.

[JÞB]

/Steen

I sort of figured YOU would avoid the obvious misuse of that method.  I am much more concerned about the front line wire slingers shooting themselves in the foot. 

This sounds like an ini token that already exists.  (am I off point? I didn't study at that ninja center!)

If so I might vote to keep it hidden to maintain LabVIEW approachability!  LAVA and LabVIEW Wiki can deal with the few dozen users that really need this exposed.  Those users tend to check the barrel without looking at it from the "working end" and tugging on the trigger to see if the gun is loaded

OTOH  I do love new features and am historically a fast adopter. 

I think you can get my kudos.....

[JackDunaway]

>> I am much more concerned about the front line wire slingers shooting themselves in the foot.

This would be a hard error to accidentally make; as improbable as accidentally wiring a 0x08 into a non-reentrant launch. But you bring up a good point, that perhaps the 0x200 option is somehow only advertised when Scripting is turned on in the IDE; the other technical solution here to to keep Open.VI with Refees as an Application method (yet, public, and officially supported) instead of working the ability into the Open VI Reference prim.

I'm cool with any implementation, even if that implementation is simply an unofficial wink that means "keep doing what you're doing... it's not going away and we've got a couple unit tests to make sure it's not going to break". 

[JÞB]

Jack, Steen submit the test case.  I agree it is needed.  I do not agree that it should be public.  I belive both of you know how to submit a test case for undocumented features.    Cross post to LAVA  This is not a new LabVIEW idea but rather exposing a "ninja" method that was stealthfully and properly undocumented.  Thanks for the info.

[Elaine_R.]

I really want this feature 🙂

Working with headless servers for code checking (jenkins) I don't have the ability to press 'ignore all' and with option 0x20 i spend alot of wasted time waiting for LV to give up...

 I'm already going to open 'every vi in my heirarchy 1x at a time' anyway to perform a code validation check, I'd be ok using a whole different open function (maybe a scripting-based open?) in order to keep casual users from calling it at random, but I would love a 'I want this vi and this vi only function'

[JonP]

Related to this is the TestStand ActiveX API Module.LoadPrototype. This is used when you are generating a TestStand Step that calls a VI using the LabVIEW Adapter. You have to call it before TestStand knows what the module parameters (i.e. VI IO terminals) are so that you can then set them to the required values. The problem is that LoadPrototype loads the VI and all its dependencies, sorry refees, which makes things very slow when you are generating many Steps that use VIs. This is a real waste of time because the prototype can surely be determined just by loading the top level VI along with any IO Typedefs.

So, when Open VI Reference with option 0x200 is implemented I hope that NI will use the underlying code inside Module.LoadPrototype