James@Work

How to use VI Package Configurations (VIPC) – VIPM

Howdy V, I have not previously done exactly what you are asking, but have done some similar tasks. We use VIPM Pro and a local repository to distribute packages not found in the public repositories; not only our internally developed packages. First, using VI Package Builder's Destinations and Source File Settings pages you can easily include the file and specify where it is installed. Second, using the Custom Actions you can specify a VI to run Before or After the package install. Use the Generate VI button to create a template VI and save into your package project; I create a Custom Actions folder when needed. Edit this template VI to launch your package configuration file; I typically rename so I know its purpose without viewing. You can use the System Exec.vi and create a constant for the command line that will include the exact install path to the .vipc file location. And, if you're not comfortable with command lines, using Open a Document on Disk.vi is another option. I'm uncertain of whether VIPM will have any issues launching a package configuration before or after a package install. However, testing this will be simple and you can include instructions for the end-users if the automation is unsuccessful. NOTE: My suggestions are based upon a Windows OS install and will need modifications for MAC or Linux Best wishes with finding a solution. James

I realize that this is an old thread, but wanted to say I had the same problem and was getting very frustrated with the loss of access to Quick Drop. This was compounded by not being able to find any uninstall functionality. 😖 Please add details for Uninstalling JKI Design Palette to the User Guide. After trying the CTRL+ALT+Space to launch the JKI Design Palette my access to Quick Drop was restored. 🙂

Great Question! I hope JKI provides some guidance with regards to how they intended these tools/options to be used. However, I doubt there's a one size fits all answer. My reason for adding suffixes is to prevent cross-linking of VIs in my VI Packages source code to those same VI in VI Packages used in my projects (Conflicts that cannot be resolved). When I'm adding functionality to the Quick Drop or Tools menu, I typically don't set them to be renamed. And, I have had problems and needed to rebuild VI Packages after realizing I'd forgotten to uncheck the renaming for dynamically called VIs that were not found after a suffix was added. If your tools development is always separate (different PC) from any project development using the VI Packages, you likely don't have to use renaming. Well, that my nickels worth.