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]

Hearty +1.

[dthor]

What's are refees?

[SteenSchmidt]

Refees: subVIs, type definitions, owning libraries... basically anything that points outside This VI.

/Steen

[JackDunaway]

A reference is one referenced by a refee. A refee is one who references a reference.

[SteenSchmidt]

Certainly, refees in the idea title could be changed to dependencies which would probably let most people understand the meaning behind the function, although "dependencies" isn't 100% covering in this case.

/Steen

[JackDunaway]

Whoa. The titled on this changed. Removing "Refee" from the title is bad, since it's an essential keyword meant to grab the attention of the intended audience. The title needs to be "Open VI Without Refees" or "Open VI Reference without Refees". The original title was good; the current title "Open VI reference without external ties" means nothing.

[SteenSchmidt]

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? And you maintain that brown banners are off limits here? It would go a long way explaining the nomenclature...

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.

[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.