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

[Aristos Queue]

The topic came up here that LabVIEW should have a way to open VIs from disk without bringing up file dialogs for every missing subVI. The idea on the Idea Exchange is still a good idea, so go give it kudos. But, in the meantime, here's my gift to you for today...

The attached "Open VI Without File Dialogs For Missing VIs.vi" will, given a path to a VI, open the FP of that VI. If there are any missing subVIs, those subVIs will be searched for on disk (unless you disable search in Tools>>Options), but if they are not found, no file dialog will appear to prompt you for where to find them. The diagram of this VI is password protected -- even though Scripting is now released, I put this together using features that are private.

The VI is saved in LV 8.0... I tested it in LV 8.5 and 8.6, but I think it works all the way back.

Open VI Without File Dialogs For Missing VIs.vi

[hooovahh]

Old topic I know, but I tried using this VI in LabVIEW 2011 and it no longer works (at least for me it doesn't). Is there an update that will work?

I realize this VI was developed before the "Ignore All" button existed in the loading window, but I'm looking to open a reference to a VI programatically. Is there a way to open a reference to a VI on disk, and have it perform the same function as if I pressed Ignore All? Thanks.

[Mellroth]

Old topic I know, but I tried using this VI in LabVIEW 2011 and it no longer works (at least for me it doesn't). Is there an update that will work?

I realize this VI was developed before the "Ignore All" button existed in the loading window, but I'm looking to open a reference to a VI programatically. Is there a way to open a reference to a VI on disk, and have it perform the same function as if I pressed Ignore All? Thanks.

How about using Open VI Reference with option 0x20?

/J

[hooovahh]

How about using Open VI Reference with option 0x20?

/J

I appreciate the suggestion but that is not a solution. The help has this to say:

Hide loading dialog box—Prevents LabVIEW from displaying the loading dialog box when searching for missing subVIs of the referenced VI.

Note This option flag does not affect whether LabVIEW prompts you to find the missing VIs or not

So it sounds like if you use 0x20 LabVIEW will not show the loading dialog, but will still be searching for the missing VIs. I want to perform an Ignore All, meaning just skip missing VIs.

Edited August 31, 2012 by hooovahh

[Mellroth]

I appreciate the suggestion but that is not a solution. The help has this to say:

Hide loading dialog box—Prevents LabVIEW from displaying the loading dialog box when searching for missing subVIs of the referenced VI.

Note This option flag does not affect whether LabVIEW prompts you to find the missing VIs or not

So it sounds like if you use 0x20 LabVIEW will not show the loading dialog, but will still be searching for the missing VIs. I want to perform an Ignore All, meaning just skip missing VIs.

Maybe I misunderstood what you were trying to do. I thought you liked to be able to silently load a VI even if it was broken?

Option 0x20 really allows you to do this; unless you also set option 0x10, the VI will silently be loaded into memory.

/J

[hooovahh]

Maybe I misunderstood what you were trying to do. I thought you liked to be able to silently load a VI even if it was broken?

Option 0x20 really allows you to do this; unless you also set option 0x10, the VI will silently be loaded into memory.

/J

I do want to load a VI silently, even when the VI is broken. I also want the load to take as little time as possible. Say I want to do this for 1000 VIs and each of them are broken for some reason. If I use 0x20 each VI will take about 20 seconds to load, for each VI it is missing. This is a guess of how long it takes LabVIEW to give up on trying to find a missing VI. However if I open it in LabVIEW as normal, I can just click Ignore All.

I would like to have the same functionality as Ignore All, but programatically. AQs previously posted VI seemed to be just what I wanted but I only have 2011 installed, and it did not perform as expected.

[Mellroth]

...I also want the load to take as little time as possible...

OK

/J

[Steen Schmidt]

I'm looking for a function like this as well - any news?

 

I want to open a reference to a large number of VIs, no matter if they are broken or not, but without waiting for LabVIEW to search for missing dependencies. I don't need the VIs to run even if they're not broken, only to be able to read and write some properties...

 

/Steen

[Michael Aivaliotis]

Would this work?

 

[Steen Schmidt]

Thanks Michael, I hadn't noticed that method. I work mainly in LV2010 to maintain broader version support for my toolsets, and that method appeared in LV2011. I would wait for LV 2012SP1 before I changed from 2010, but maybe I should jump to 11 before that, even though 2012SP1 is just around the corner... pondering...

 

Anyways, that's an interesting method, and could maybe help in some way. I'm not sure yet of how much functionality (VI hierarchy, ownership and family ties etc.) is retained loading a VI this way, but it looks promising. I'll delve into it. Thanks!

 

/Steen

[JackDunaway]

Would this work?

 

2013-02-21_1157.png

 

This was my first thought also. This is an extremely handy method for performing VI server tasks on a single VI that don't require its static hierarchy to be loaded (psstt... this method can be orders of magnitude faster than Open VI Ref since, not only does it not load static dependencies, it does not load the owning library definition or sibling members).

[hooovahh]

This was my first thought also. This is an extremely handy method for performing VI server tasks on a single VI that don't require its static hierarchy to be loaded (psstt... this method can be orders of magnitude faster than Open VI Ref since, not only does it not load static dependencies, it does not load the owning library definition or sibling members).

It is very fast.  I did a test on it by having it find all VI recursively in a directory, then open each of them and read the Connector Pane Image, VI description, VI Controls and their descriptions.  Finding the VI files took longer than performing all the other operations.

 

EDIT: Actually I had a bug in my code the timing is not quite correct. On a directory containing 440 VIs (in sub folders too) it took 71ms to find all of them using the Recursive File List.  Then it took another 4.8s to open those 440 VI references.  The time to read the data was a bit flawed too but is on the order of 8-10 seconds.

Edited February 25, 2013 by hooovahh

[JackDunaway]

Would it be worthwhile to create an Idea Exchange entry suggesting that Open VI Ref have a new option, 0x200 for example, that would behave the same as this private function? This feature is incredibly more performant for tasks such as what hooovahh describes above.

[hooovahh]

Occasionally I will be working on multiple projects that at one time split from each other.  Because of this there will be many VI with the same name in both projects.  To keep things simple I will only open one project at a time, but sometime I will do something stupid and have one project link incorrectly to the other projects VI.  A tool I've wanted to make is to open a ref to all VIs in memory, get their paths, and build a tree with a directory view of all VIs loaded.  This way I can see quickly which VIs are being called from where on disk.  This type of tool could take advantage of this private method because I don't care to load all other dependencies when I open my references.  I just need to know the path (and assume all the VIs are already in memory) that I want to scan.

[hooovahh]

Sorry I can't edit my own post (too old) but for those having cross link issues like the one I mention, looking at the Files tab in a project explorer will quickly show any VIs not linking to the right files on disk so the tool I mentioned making isn't needed.

[Steen Schmidt]

Would it be worthwhile to create an Idea Exchange entry suggesting that Open VI Ref have a new option, 0x200 for example, that would behave the same as this private function? This feature is incredibly more performant for tasks such as what hooovahh describes above.

 

I definetely think so. It runs nicely in the vein of the existing option 0x20 (do not display the loading dialog). That option list was the first place I checked when looking for this functionality. Will you post such an idea?

 

Cheers,

Steen

[JackDunaway]

I definetely think so. It runs nicely in the vein of the existing option 0x20 (do not display the loading dialog). That option list was the first place I checked when looking for this functionality. Will you post such an idea?

 

Cheers,

Steen

 

Rather than adding it to my (lossy) IdEx queue; by all means, I would gladly vote for your post -- and remember, etiquette there would suggest not showing a brown banner on an invoke node :-)

[Steen Schmidt]

Check!

 

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

 

Let's see if it catches on.

 

Take care!

 

/Steen

[doradorachan]

Hi guys,

 

I think this is what I exactly need right now.

 

Would this work?

 

2013-02-21_1157.png

 

How do you enable the brown-bannered property nodes? Is there a key I need to input in the LabVIEW ini file?

 

Thanks

[hooovahh]

How do you enable the brown-bannered property nodes? Is there a key I need to input in the LabVIEW ini file?

Here is a handy table.

 

http://digital.ni.com/public.nsf/allkb/2FF365A6FAB7B34786257ACD004BA15A

 

Basically these are properties not ready for prime time.  Maybe their functionality only works in some limited cases, or maybe NI is unsure if they want to allow non NI people to be able to use it, or maybe NI hasn't got around to documenting the functionality, or any other reason NI wants to not make the function well known.

 

Because of that these functions may change from version to version, or be removed all together.  It is said that private methods should not be used in production code, and NI will not support applications written using them.

 

But they are powerful tools and LabVIEW experts love to dig into these types of things and make tools that normally wouldn't be possible.

 

I made a tool a while ago that goes into the Tools menu when turns on and off these private methods.  

 

http://lavag.org/topic/16612-enabledisable-private-methods/

 

Basically yes there is a "super secret" ini key that enables these features.

[doradorachan]

Didnt notice your response because my notification setting was off.

I will try out your VI. Thanks!

[hooovahh]

Okay did NI change something, or am I crazy?  I only have access to 2013 SP1 and 2014 SP1 at the moment but both of them don't appear to work as I thought this function used to.  Attached is a VI saved in 2013 which should get the path to the Add File to Zip.vi in the vi.lib.  It will then use this private function and try to read the VI Description.  When it does it returns an error that the reference is no longer valid.

 

So I ask again, am I crazy?  Or did this undocumented function just demonstrate why it was undocumented?

 

EDIT:  Okay this might be because the VI is opened in a new application instance, and if it isn't being used it closes, which closes the VI references opened in that application instance.  Because I noticed if I took the App Ref output and closed it manually later, then everything works as expected.  Is this new?

Open Without Refees.vi

[agilentvee]

could you give us the VI's password??

 

i cannot view the block diagram

[hooovahh]

The first post is password protected for a reason and AQ mentions this.

 

 

 

The diagram of this VI is password protected -- even though Scripting is now released, I put this together using features that are private.

The private functions he used in 8.6 have not become public since then.  If you have private methods enabled I believe he is using the Application >> UnattendedMode, setting it, then opening the VI refs, then clearing that.

[JackDunaway]

Okay did NI change something, or am I crazy?

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.