Jump to content

Installing multiple VIPM 2.0 packages


chrisdavis

Recommended Posts

Jim et al,

I've got several reuse library VIs that I would like to package into several (15ish) VIPM 2 packages. VIPM 2 has made it mucho easy to put together nice looking palette's. Now I want to make a palette of all my various packages and make the installed items look the same in all installed computers, in much the same way that OpenG does with its packages. Any advice?

 

Thanks

Link to comment
Share on other sites

Hi Chris,

 

I'm happy to hear that you're on-board with VI Packages for your your VI reuse system :)

 

First off, let's clarify what you're asking for: I assume that what you're wanting to do is create a root-level category in the Functions palette (similar to the OpenG palette, shown below), rather than having your palette installed in the standard locations (User Libraries, Instrument Drivers, Addons) supported by the VIPM's package builder?

 

1.png

 

Doing this involves the following:

 

1] Create a special "palette package"

You will need to use OpenG Package Builder to create a special "palette package" (e.g., called "org_rsc_palette", where "org" is the name of your organization and "rsc" is used to signify that that the package is a resource and not a library). There are a couple key things that should be noted about this package:

  • The palette package should install a single MNU file (e.g., "org.mnu") into the "\menus\categories" folder (installing MNU files here causes them to show up as root-level categories).

  • This palette (MNU) needs to be set to synchronize with the folder (e.g., \_org.lib\palette) where each of your library VI Packages will install their individual palette MNU files -- this is what causes each of your libraries' palettes to show up beneath your organization's palette category. Note that the underscore in "_org.lib" folder name is critical to avoid having all of your organization's library VIs show up in the User Libraries palette, which we do not want for this custom configuration.

2] Configure your library VI Packages for use with the "palette package"

 

2.a] Configure custom installation locations

 

In each of your VI Package Configurations, you should configure custom Installation Locations, in the Advanced Build Parameters dialog, as shown below:

 

2.png

 

Set the following parameters:

  • Installation Location = .
  • Library VIs Installation Folder = \_org.lib
  • Functions Palette MNU Installation Folder = \_org.lib\palette
  • Controls Palette MNU Installation Folder = \_org.lib\palette

2.b] Configure dependency on "palette package"

We want to make sure that the library packages show up in the palette -- they depend on your palette package to achieve this. So, you will need to open the VI Package Configuration for your library VI Packages, by pressing the Open VI Package Configuration button on the Dependencies page of the Advanced Build Parameters, as shown below:

 

3.png

 

Add to the "org_rsc_palette" package to your VI Package Configuration by dragging & dropping it from the VIPM main window's package list into the VI Package Configuration list, as shown below (note that your palette package must be added to VIPM's package list or installed, by this point):

 

4.png

 

Save and close your VI Package Configuration. Re-open the Dependencies page of the Advanced Build Parameters, and you will see the palette package in the dependencies list, as shown below:

 

5.png

 

Finally, make sure that that dependency is an External Dependency (rather than an Internal Dependency, which it is by default), as shown below:

 

6.png

 

That should do the trick. Also, it's on our roadmap to add this sort of functionality into VIPM Professional. If you need any help creating your palette package (especially the MNU file), don't hesitate to ask. The process for creating this MNU file can be a little tricky -- Customizing the LabVIEW Palettes is (Ridiculously) Hard, you know :)

 

Thanks,

 

-Jim

Link to comment
Share on other sites

First off, let's clarify what you're asking for: I assume that what you're wanting to do is create a root-level category in the Functions palette (similar to the OpenG palette, shown below), rather than having your palette installed in the standard locations (User Libraries, Instrument Drivers, Addons) supported by the VIPM's package builder?

 

Actually, I was going to be content with putting all of my work under the User Library, but now that you've shown me another way, I will be checking this tutorial out.

 

To clarify, currently I navigate to User Libraries, then I have a subpalette there with my org name, then under that several subpalettes that contain my reuse VIs, as seen below.

palette_layout.png

I did it this way because no tutorial existed on how to do it another way. If I want to continue doing my reuse library this way, what parts of your tutorial would have to change?

 

BTW, thanks for producing this quick tutorial, I'm going to discuss this idea with my other users to see if it will help out.

Link to comment
Share on other sites

Hi Chris,

 

I've been meaning and wanting to create that tutorial, since I know that there are at least a few of our power users out there who want to use that sort of setup.

 

To do what you're after (have all your organization's libraries show up in a common sub-palette under User Libraries), you can simply set the the custom installation locations to the following:

 

1.png

 

This will cause all of your libraries to show beneath a "OrganizationName" supalette of User Libraries (since LabVIEW will see a "OrganizationName" and create a dir.mnu file inside it that is synced to the "OrganizationName" folder). The only drawback of this "quick and dirty" technique, is that you won't have a pretty icon for your OrganizationName subpalette. However, you can always modify this mnu file and create a package that overwrites it (and make all your library packages depend on it, as described earlier).

 

Thanks,

 

-Jim

Link to comment
Share on other sites

However, you can always modify this mnu file and create a package that overwrites it (and make all your library packages depend on it, as described earlier).

Jim,

I've been doing just that.

 

I also thought I would try out your tutorial above and I've almost got it the way I want it. I am having trouble with, as you have guessed, creating the mnu file correctly. I seem to have it setup just perfectly for the functions palette, but whenever I try to get the controls palette to show up with the same mnu file I run into snags. I'm thinking maybe I need to distribute two mnu files both of which sync to the org\palette mention above. One of these proposed mnu files would handle putting controls on the controls palette and the other would handle putting functions on the functions palette. I just thought I would ask if I'm missing something before I go down this path.

 

I think I'm going to keep the method you've "tutorialized" (pardon the coined phrase) above because the group likes it. And, it seems fairly straight-forward to implement.

 

Thanks!

Link to comment
Share on other sites

Jim,

I've been doing just that.

 

I also thought I would try out your tutorial above and I've almost got it the way I want it. I am having trouble with, as you have guessed, creating the mnu file correctly. I seem to have it setup just perfectly for the functions palette, but whenever I try to get the controls palette to show up with the same mnu file I run into snags. I'm thinking maybe I need to distribute two mnu files both of which sync to the org\palette mention above. One of these proposed mnu files would handle putting controls on the controls palette and the other would handle putting functions on the functions palette. I just thought I would ask if I'm missing something before I go down this path.

 

I think I'm going to keep the method you've "tutorialized" (pardon the coined phrase) above because the group likes it. And, it seems fairly straight-forward to implement.

 

Thanks!

 

Hi Chris,

 

Keep me in the loop on your progress with the Category MNU file and let me know if you need any help getting this working -- your solution for using two MNU files might work, too, but you should be able to do it with one MNU (since MNU files can contain one Functions Palette and one Controls Palette).

 

I'm here to help.

 

Thanks,

 

-Jim

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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