It would be great to see (or be able to filter out) toolkits, which are registered by Third-Party Activation Toolkit, and see its statuses. Because it happens, that some toolkits have trial period, then it is expired - and LabVIEW warns about it. When one wants to remove these toolkits, he has to open VIPM - but then he needs to search those packages by name.

But if - for example - first time user turns off notification window in LabVIEW for expired license, he does not see it in future. But, there are still toolkits with invalid (expired) license - and when he wants to uninstall them, he needs to open Activation Add-On window, check toolkits and their statuses, go to VIPM, and remove them.

If there would be statuses visible in VIPM, then one sees it directly there, and could manage - either buy/prolong license, or uninstall toolkit so he will not be bothered by it in the future.

This feature is not important, because such situation occurs quite seldom, but it could make routine a bit easier.

Thanks a lot,

Sincerely, kosist90.

It would be awesome if there were a way to programmatically read the contents of a VIPC file. I don't know that there's a way to do this yet using the VIPM API

I have a Surface Book 2 with a 3000x2000 pixels 13.5" screen. With screens like that its mandatory a way to change the font size. I suggest adding a ability to change the package list font, at least.

The show in palettes button in the package information dialog does not support xctl? If only xctl is added to the controls palette without ctl or vi, then the button is disabled after the package is installed.

The search text field doesn't handle key down and hold events / repeat. For example holding down the delete key should strat deleting multiple characters after a while. Same for the cursor keys moving the caret position - it doesn't work when held down.

Use the ShellExecute WinAPI function to automatically open links in the default browser for Windows systems.

IE is horrendous.

When i quickly want to have a new LabVIEW installation on another PC or VM, I can let run the LabVIEW installation unattended, but then it takes quite some presence-time to re-install all the VI packages with VIPM. So I usually just copy the whole LabVIEW user.lib folder over to the new VM. While LabVIEW gathers/auto-populates the user libraries automatically and the packages vi folders show up as palettes, VIPM doesn't do this, what in my eyes would be expected behavior. The whole VIPM packages list stays empty even though all the packages are there on disk. But maybe I oversee something, and there is already a way to make this auto-population happen...?

Installing a package with a custom functions palette to the folders user.lib or instr.lib (eg. user.lib/My Library) results in duplicate entries in the functions palette when the package is installed.

This is due to automatic synchronisation of the functions palette within these folders. Adding an (_) underscore in front of the package installation directory (e.g. user.lib/_My Library) skips LabVIEWs automatic synchronisation of the functions palette and therefore only shows the custom functions palette like expected.

I would like VIPM to check if a package will be installed to one of these folders (without an underscore as the first letter) AND does have a custom functions palette. If so, VIPM should show a hint like "...this will result in duplicate function palettes entries..." (or something better). At least, this fact should be better documented.

I built a hardware driver, all VIs are part of a library. The library contains some unit testing VIs which I don't need as a part of the VIP distribution, so they are marked as "Exclude from Package" on the Source File Settings section of VIPB.

However, as these VIs are a part of the library, when excluded from the build they cause the library to list them as missing dependencies when the VIP is installed on a development machine (the little yellow exclamation marks in the Project View).

If I move the VIs to outside the library this creates scoping issues with certain private dependencies only accessible from within the library, so they must remain within the library.

Ideally, VIPBuilder would repair the library by removing these dependencies safely within LabVIEW (not just excluding the files from the package) and thus maintaining library integrity. Maybe his can't be done.

But can I ask, what's the proper way to exclude VIs from the package that are listed as belonging to a library without the library becoming bad?

For some reason i get an error when opening a package in the creator from the Latest package list, this error seems to stick, as further clicks on the Build package button doesn't do anything. 

What i need to do is restart VIPM and Build Package and select Open package.

I have built a number of internal libraries where I want the same support on desktop and RT palettes. This involves recreating the palettes from scratch currently.

There should be an easy way to have the same palette on both.

A feature or function to display a hierarchy of packages showing the dependencies between different packages, based on a selection of packages, what is currently installed, or all packages in a package configuration. Similar to the VI or class hierarchy in LV.

Kami menjual Jual obat suplemen peninggi badan tiens murah asli dalam bentuk paketan, kenapa begitu? maksudnya biar sesuai dengan badget (uang) dan kebutuhan konsumen, karena setiap orang budget dan kebutuhan ingin naik tingginya berbeda. Sudah jelas kan? 😉 Anda bisa memilih Harga Paket Suplemen Peninggi Badan Tiens berikut ini sesuai badget kemampuan uang dan kebutuhan ingin naik tingginya :

It will be nice to have a property/option to exclude newly added folders from package by default. As of now any new folder under Source directory is included in package as default, It will be nice to somehow exclude new folders by default.

I have situation where I feel this option will be very useful.

I and my team are creating lots of Instrument drivers for internal purpose and release them very frequently. We have all our code under Instrument Driver folder. Instrument Driver folder includes sub folder (category of instrument drivers like Power supply, RF etc) and menu files that needs to be deployed while installing packages. With help of menu files drivers will be shown up in LabVIEW functionally palette.

Say to build Keithley 24xx, I need to include Instrument Driver as source directory and include Keithey 24xx folder and whole hierarchy of Instrument Driver menu files (ie the menu file directly inside Instrument Driver and the one inside Power Supply folder) and build package over it. Rest of the unnecessary folders are excluded from packages. Please see I need the whole hierarchy of menu files so that in the LabVIEW palette drivers are shown in the same level/folders as shown in window explorer (Instrument driver -> Power supply -> Keithley 24xx)

1. Whenever a new folder or driver category is created under Instrument Driver, the next time in Keithley package, the new folder is included in the ‘Source file setting’ by default, which is NOT needed. So exclude folders by default will be helpful here.
2. When there are multiples PC used for development purpose, there comes one more situation. VIPM removes file exclusions if source code folders aren't located on the machine where the build spec is being modified. So take the same example:
   1. A build spec is created on machine1 with this source directory: Instrument Driver
   2. Inside of that folder are several other folders: ...\Power Supply\Keithley 24xx, ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix.
   3. In the source file settings ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix are EXCLUDED from package
   4. The build spec is saved and closed
   5. The build spec is opened on machine2 that only has ...\Power Supply\Keithley 24xx folder
   6. VIPM will remove the folder exclusions properties of..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix (as folders are missing)
   7. The build spec is saved and closed
   8. The build spec is opened again on machine1
   9. The build will now include ..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix which were excluded first time but in the second build their properties were lost and now VIPM thinks they are newly encountered folders and include them by default.

This causes lots of issues and before each build developer has to verify the ‘Source file settings’ causing consumption of time.

I not sure if this got bought up before (in the beta?) but I would like a better UI for interacting with dependencies then there currently is. I just find it hard to find what I want unless I know the exact spelling of the package name (VIPM 3.0) or display name (VIPM 2010) and scrolling through everything is not that fun 

Sometimes my source for folder has old (or not yet finalized) VIs that I don't want to distribute, in my project I remove these VIs from the library/class, but since VIPM picks a whole folder as the build-source these VIs show up in the package. 

By selecting library or class as the build source these functions wouldn't be included.

when creating a new VIP, automatically "exclude from build" folders that match user-defined strings (preferably compatible with labview regular expressions or PCRE). I suggest this because we have a well-defined file structure in our source code repository. all files in certain folders are never included in the build because they are only used during development. It would be nice if this could be auto-configured but only when creating new packages (so there are no surprises when opening an existing package).

It would be really cool if I could add multiple dependency packages to a package as sub-packages so I could ship one package that contained all required packages. 

I can currently do this with a .vipc file, but love the idea that a package could do it.
Another good reason for sub-packages over .vipc files that I forgot to mention: .vipc files currently have to be installed in the same version they were created. For example, this means that to support multiple versions of LabVIEW for a package release, I have to add multiple .vipc files if I want to include dependencies + package in a .zip release. 

To start with I don't mind if its not exposed through the UI - as I would more than happy to do it myself with hooks. 
Backwards support for OGPB would be nice too.

I ventured into the wonderful world of VIPM package building recently, and am impressed. However, one thing that immediately caused me issues was the use of a Source Folder as the root of the package definition. I wanted to point VIPM at my existing LabVIEW Project. Why? Because in my harddisk folder I have VIs not included in the Project, legacy files and VIs no longer in use. When pointing VIPM to the root folder it automatically picked up all these unwanted files, and it was a nightmare of "build error" after "build error" attempting to find them all and selectively remove them from the "Source File Settings" tree.

Idea: Can VIPM analyse the LabVIEW Project tree in the first instance of creating a new package to determine which VIs (files) are wanted and which are not to initialise/populate the Source File Settings?

I ran into the situation a few times when I wanted to abort what I was doing but couldn't. This seemed to be for network tasks. I thought it would be cool if I could abort these in the future.

I thought a cool new feature would be to allow adding multiple files on Insert... >> VI... to the Palette Editor instead of one at a time (and opposed to the entire folder). 

I would be nice to have the ability to install a package directly into a end user specified project folder instead of being forced to install to a set location.  This would be similar to how NPM manages dependencies for Javacript node.js projects.   

I assume this package would not be installed onto any of the pallets, but it would allow a user to work with multiple projects using different versions of the same packages.  You wouldn't have dependency overlap of installing things into your labview program files or OS user file locations.  I guess this would just be an extension for packed project library but with versioning built in

After starting my build process, and waiting for about 10 minutes, it bombed with an error related to validation of the Automated Online Activation URL. This check is performed by calling "_ValidateAutoActivationURL.vi" from the NI_LV2PLicAPI.lvlib, and can therefore be done at any time. Can I request that this check is performed at the very beginning please? Thanks.

Star Ratings

With most things you can download these days there's usually some form of user rating, namely in the form of a score out of 5 stars, such as 

The best of the best

There are so many packages on VIPM now, and some I've never seen before and have never tried, that I wonder which ones I might be missing out on. I can't install them all, but if each were to display a star rating I could quickly pick out some candidates to try! I would know that these ratings would be coming from LabVIEW users and that I could trust them to be an honest reflection on the usefulness of the package.

NI Tools Network

The NI Tools Network already implements a ratings system, can we have something similar for the packages list view window? Clearly those that are supported on the NI Tools Network repository would need their rating to come from NI.

Submission

Of course, the ratings need to come from somewhere, and that would be us users. I think it would be great if you were able to provide your own rating for packages you have installed. If you are uninstalling a package, VIPM could ask you to provide a rating whilst it uninstalls so that you can provide feedback on why - it maybe that you hated it and this way you get to provide a low rating.