Open Library Without Dependencies?

[hooovahh]

Is there a way to open a library reference without loading the dependencies?  There exists a function to open a VI as mentioned here.  Is there a similar thing for libraries?  I basically just want to get the file structure of the files in the library, and possibly add a file to the library.  I think I can do this with pure XML parsing but don't feel like going down that rabbit hole if it isn't needed.  Thanks.

[dadreamer]

I'm not aware of such a method. Maybe this example can help somehow: Get Library Icon (lvlib, lvclass, xnode, xctl) without loading dependencies in memory

[Darren]

For a regular library (.lvlib), opening a reference to it (via the 'Library.Open' method) will not bring member VIs into memory.

For a class (.lvclass), opening a reference to it (via the Library.Open method) will bring all member VIs into memory. There's no way around this behavior that I know of.

[hooovahh]

Thanks Darren.  Just for a little bit of background.  I'm trying to make a VIPM package, that when installed doesn't popup all the time asking to find missing VIs, if they are part of NI toolkits that aren't installed.  The primary example I have is I have some CAN packages, that use the NI XNet library.  If you install the package before XNet then you get dozens of browsing dialogs trying to find things that it will never find.  It makes the install take much longer waiting for the timeout of each, or clicking "Ignore All" constantly.

One of the reasons the browse dialog appears is the Post Install VI edits the any Libraries, and Classes to add the MNU to it, and setting it to the Default menu.  So attached is some very incomplete and hacky code that can edit a Library or Class at the XML level to add an MNU file to it, and set it to the default of that library type.  That way when you right click a class it brings up that menu palette.  This seems to work well enough and just needs some clean up and testing.  

I did find another source of browse dialogs during a package install, and that is that I also might edit an MNU to add or remove subpalettes, as part of the Post Install, and Pre Uninstall.  I haven't finished troubleshooting but it appears that the Write Palette function causes the browse dialog to come up, if some dependency of a VI is missing.  I may need to dig a bit deeper, or just live with these couple of browse dialogs.

@dadreamer, thanks for the suggestion, but in this case that won't work.  That code basically creates a blank library, bringing over only the icon part, and then it reads the library using the normal functions.  The only way I could see that technique working here would be to replace all VIs with empty VIs, and then use the normal functions to read the library structure, then replace them back.

Set Default MNU In Library Without References.zip

[Darren]

Can you use the private UnattendedMode property in your post-install VI? The searches would still take place, but at least you wouldn't have to see the dialogs?

Could you replace the calls to possibly-missing VIs in your code with dynamic calls? This would work if there were only a few calls.

[ShaunR]

Doesn't VIPM check the dependencies before installing or can't you check for the dependencies in the pre-install.vi?

[Darren]

I assumed he was referring to non-VIPM dependencies, like NI installers which, to my knowledge, VIPM doesn't check for. But you're right, he could look for the dependencies in his pre-install VI. But maybe his package is still useful even if those dependencies aren't installed?

[hooovahh]

Yeah what Darren said.  Still I think with a combination of Pre Install checks, and the dynamic loading I can come up with something that works.  Oh or an XNode that drops a copy of a dynamically loaded VI, if that VI isn't broken?  I did start digging into the palette editing code a bit.  It seems something inside the "Palette Menu.lvlib:Set Items.vi" is causing the browse dialog when palette items are missing.  Looking at it I can't see any place that would open a reference to it, so I'm not sure why it is doing it.  By the way I'm not sure who to thanks for the fact that the palette editing code appears to be all G, but it is nice.

[ShaunR]

53 minutes ago, hooovahh said:

Yeah what Darren said.  Still I think with a combination of Pre Install checks, and the dynamic loading I can come up with something that works.  Oh or an XNode that drops a copy of a dynamically loaded VI, if that VI isn't broken?  I did start digging into the palette editing code a bit.  It seems something inside the "Palette Menu.lvlib:Set Items.vi" is causing the browse dialog when palette items are missing.  Looking at it I can't see any place that would open a reference to it, so I'm not sure why it is doing it.  By the way I'm not sure who to thanks for the fact that the palette editing code appears to be all G, but it is nice.

When VIPM doesn't do what I need, I create an installer with a post install VI that runs it and a post uninstall that deletes it. VIPM just copies it to the correct location.

[hooovahh]

21 minutes ago, ShaunR said:

When VIPM doesn't do what I need, I create an installer with a post install VI that runs it and a post uninstall that deletes it. VIPM just copies it to the correct location.

Sure but if you have an installer, and it also needs to manipulate an MNU to files that have external dependencies that are missing, you are going to see the same Browsing dialog, or if you try to edit a library to add an MNU to it you'll have the same issue.  This isn't a VIPM issue, but instead an order of installation issue.  I think having a Pre Install VI that just checks for the installed component, and then gracefully fails the package install will work fine.

[ShaunR]

56 minutes ago, hooovahh said:

Sure but if you have an installer, and it also needs to manipulate an MNU to files that have external dependencies that are missing, you are going to see the same Browsing dialog, or if you try to edit a library to add an MNU to it you'll have the same issue.  This isn't a VIPM issue, but instead an order of installation issue.  I think having a Pre Install VI that just checks for the installed component, and then gracefully fails the package install will work fine.

I agree. That solution is by far the easiest and simplest. I'm just lucky that I have an installer (written in LabVIEW) that can generate the mnu files on-the-fly. So deciding which menu items to add wouldn't be difficult.

In fact. thinking about it. You could probably do something almost as good if you could segregate the icons into palette sets, made each a separate mnu file, and then, during the pre install, copied over only the ones you wanted based on what was installed. LabVIEW would probably do the rest or you could force it to recompile the entire mnu hierarchy in the post install.

Edited April 19, 2022 by ShaunR

[hooovahh]

21 minutes ago, ShaunR said:

In fact. thinking about it. You could probably do something almost as good if you could segregate the icons into palette sets, made each a separate mnu file, and then, during the pre install, copied over only the ones you wanted based on what was installed. LabVIEW would probably do the rest or you could force it to recompile the entire mnu hierarchy in the post install.

Yes that's what I do with VIPM.  There is a Post Install VI that either adds subpalettes, or runs VIs in the package that defines what palettes to edit and how.  For instance you might install a new package and all it does is add a class to the palette along with the other ones.  It could add an Advanced subpalette for instance.  Or adds a subpalette in a specific row and column.  But some are just a list of all sub palettes in alphabetical order.  This all works just fine if the required external dependencies are installed.  But if they aren't then I wanted a way to install them without a hundred missing VI dialogs.  A second best is to just not allow installing it at all.

[ShaunR]

There must be something I'm missing.

1 hour ago, hooovahh said:

There is a Post Install VI that either adds subpalettes, or runs VIs in the package that defines what palettes to edit and how.

Right. So it can add or not depending on whether the dependencies are installed. Shouldn't this be the pre install,? VIPM will try to compile the menu before the post install. Is this where you are getting the dialogues because all mnu's are created as part of the VIPM package and are therefore present when VIPM makes the palette at install?

1 hour ago, hooovahh said:

But some are just a list of all sub palettes in alphabetical order.

OK. But if the sub palettes are separate mnu's, you just don't include those that are for those not installed, right? If you copy over only the mnu's you need (or use your previously stated VI's to make them) and don't rely on VIPM to compile the menu's (no mnu's as far as it is concerned) then no dialogues will be thrown. You just then need to make LabVIEW compile the mnu's at the post install or rely on LV to auto compile them

[hooovahh]

13 hours ago, ShaunR said:

So it can add or not depending on whether the dependencies are installed. Shouldn't this be the pre install,? VIPM will try to compile the menu before the post install. Is this where you are getting the dialogues because all mnu's are created as part of the VIPM package and are therefore present when VIPM makes the palette at install?

I'm currently getting the dialogs because trying to edit a class by adding the MNU to it, but having missing dependencies causes the browse to show up.  This is currently a Post Install VI.  This issue I worked around with the code posted that does this without using VI Server.  And secondly I found that editing an MNU that has VIs that are missing dependencies also causes the browse dialog.  A Pre Install VI to check if external dependencies are installed can fix this by failing to install.  Hopefully the error can be passed back up to VIPM where it can tell the developer something like "Install XNet before installing this package".  But as Darren said there are some tools in it that are useful even if XNet isn't there, and ideally I'd like to install the package before XNet, and just have some of those functions not available.

13 hours ago, ShaunR said:

OK. But if the sub palettes are separate mnu's, you just don't include those that are for those not installed, right? If you copy over only the mnu's you need (or use your previously stated VI's to make them) and don't rely on VIPM to compile the menu's (no mnu's as far as it is concerned) then no dialogues will be thrown. You just then need to make LabVIEW compile the mnu's at the post install or rely on LV to auto compile them

Some aren't sub palettes, and are just items on the base palette.  For those I could have a Post Install that opens up the MNU and remove the entries to items that require the XNet install, if it is missing.  That way the package can be installed, just some items won't be available that use it.  I'd still not be able to edit the Class adding the MNU to it, without causing browse dialogs, or using my custom code I posted earlier.

[ShaunR]

1 hour ago, hooovahh said:

I'm currently getting the dialogs because trying to edit a class by adding the MNU to it

OK. That's the bit I'm missing. Maybe a silly question but why? Is there a specific scenario where this is desirable? LabVIEW palettes aren't scoped and I have never included them as part of a class; so I'd be interested of the benefit. I've always included them as external file regardless of class since some palettes may have multiple classes in them.

Edited April 20, 2022 by ShaunR

[hooovahh]

46 minutes ago, ShaunR said:

OK. That's the bit I'm missing. Maybe a silly question but why?

If you have an MNU inside a class (or library really) you can set it as the Default Menu for items in that class or library.  Then if you right on members of the class, or the class constant, then the menu you specified will be available as a shortcut.  Lets say I install a File IO package with a palette for it.  And then I install as Zip package.  I might want that zip package to insert items in the File IO palette, or I might want to make a subpalette for the Zip, or make a subpalette under Advanced for the the zip which is also in the File IO.  In any of these cases you can then add the MNU to the zip class, and set it to the default.  Now I can have the File IO palette come up if I right click a Zip class, or I can have it come up with the subpalette if that's what I did during the install.  Here is some information on it.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/setting_default_palette_menus/

https://forums.ni.com/t5/LabVIEW/Here-s-a-scripting-VI-for-LVClass-default-menu/td-p/2429356

In the scenario I described you'd want to edit the Zip class, but you also will need to edit the File IO palettes, either adding Zip items, or adding subpalettes to it, or linking the Zip palettes to it some where.  Doing this causes browse dialogs if say a required Zip DLL was missing and needed to be installed as part of the system.  In that case I'd just include the DLL, but in my actual dependencies is XNet which can be a 1GB install so including that in the package isn't ideal.

[ShaunR]

33 minutes ago, hooovahh said:

If you have an MNU inside a class (or library really) you can set it as the Default Menu for items in that class or library.  Then if you right on members of the class, or the class constant, then the menu you specified will be available as a shortcut.

Who said you can't teach an old dog new tricks

I'll have to have a play but generally I use polymorphic VI's for that.