Jump to content

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


Recommended Posts

  • 3 years later...

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.

Link to comment

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

Link to comment

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 by hooovahh
Link to comment

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

Link to comment

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.

Link to comment
  • 5 months later...

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

Link to comment

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

Link to comment
Would this work?

 

attachicon.gif2013-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).

Link to comment
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 by hooovahh
Link to comment

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.

Link to comment
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

Link to comment
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 :-)

  • Like 1
Link to comment
  • 1 year later...
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.

Link to comment
  • 3 weeks later...
  • 9 months later...

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

Link to comment

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.