Here's a way to open VIs without file dialogs for missing subVIs

[jgcode]

Both, pal! But in LV13.0bxx era, I asked the same question, and the unofficially-reworded response was "yep; we [NI] changed this because previous to this change the AppRef was leaking; just keep it open til you've done what you need to do with the newly-created VIRef, then `Close Reference` on the AppRef and it'll work like it used to, just less-leaky".

I've used that guidance for 2yrs now with success; your independently-discovered `*Edit` is the correct way to use this method now.

 

Does this mean old code will be 'broken' in 2013+?

[JackDunaway]

Does this mean old code will be 'broken' in 2013+?

 

Likely; mine was, and it appears @hooovahh's was also. One patch for backwards compatibility is to dynamically dispatch via CBR a version saved in LV for <2012 and another for >=2013.

[hooovahh]

My use was I had some tools that prepare code for getting ready to package it up using VIPM.  This is the same tools I've used on things like my Variant Repository and Circular Buffer.  I would run a VI that opened the code, removed compiled code, turned off debugging, automatic error handling, lock the VI (no password), and add some text to the VI Description.  So for me I wrote the code to work in the oldest version of LabVIEW supported.  So when I was packaging up code that worked in 2011 and newer it worked fine.  When I had a package that needed to be 2013 and newer I tried running the same code, which is when I found this change.

 

Good to know I'm not crazy.  Also I guess its a good thing this is a private function.  Finding bugs in private functions makes me feel like NI did the right thing by not making the function public.  But I'm sure we have all the bugs worked out now so it can be public right....right?

 

Related idea exchange.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Open-VI-reference-without-refees/idi-p/2329706

[jgcode]

Ok, so its not all AppRef functions that are effected, just the one in this post 

That's a relief 

[dadreamer]

On 2/23/2013 at 12:21 AM, JackDunaway said:

not only does it not load static dependencies, it does not load the owning library definition or sibling members

This is true. But! If the VI to open is a member of a lvclass or lvlib and the typedefs input is False (default value), then almost any subsequent action on that VI ref leads to the whole hierarchy loading into memory. This is not good in most cases as with large hierarchies loading takes several seconds and LabVIEW displays loading window during that, no matter which options are passed. The only easy way to escape that is to set the typedefs to True. Another option would be putting the VI in a bad (broken) state, but the function suitable for this is not exported. Frankly this Open.VI Without Refees method acts a bit odd, because when the typedefs is False, it sets the viBadVILibrary flag, but it does not give the desired effect, but when the typedefs is True, such a flag is not set, but no dependencies are loaded.

Sometimes I use Open.VI Without Refees to scan VIs for some objects on their BD's / FP's and when there are thousands of VIs, it all takes many minutes to scan, even with the typedefs = True. I managed to speed things up 3-4 times by compiling my traversal VI and running it on a Full Featured RTE instead of a standard RTE to get the scripting working. Using that ~20 000 VIs are scanned in about 5 minutes.