-
Content Count
14 -
Joined
-
Last visited
Community Reputation
3 NeutralAbout James@Work
- Birthday December 8
Profile Information
-
Gender
Male
-
Location
Houston, Texas
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Retrieving version of installed packages in LabVIEW
James@Work replied to Mario's topic in VI Package Manager (VIPM)
How to use VI Package Configurations (VIPC) – VIPM -
James@Work started following VIPM - Any Future Updates?, Distribute VI package configuration and VIPM - Any Future Updates?
-
Distribute VI package configuration
James@Work replied to Vollinger's topic in VI Package Manager (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 C -
fixed JKI Design Palette messes up LabVIEW search
James@Work replied to KarelM's topic in JKI Design Palette
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. 🙂 -
Best Practices Question - Renaming Source Files
James@Work replied to hooovahh's topic in VI Package Manager (VIPM)
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 -
James@Work changed their profile photo
-
Our company continued our VIPM licenses last year and most of them are about to expire. However, since JKI has NOT released any new versions (fixes, improvements, etc.) since before our last year's upgrade, it appears any future purchase would likely be another waste of money? Please let us know if JKI is has decided to stop new development, bug fixes and enhancements for VIPM. Thanks & Regards, James
-
Our company continued our VIPM licenses last year and most of them are about to expire. However, since JKI has NOT released any new versions (fixes, improvements, etc.) since before our last year's upgrade, it appears any future purchase would likely be another waste of money? Please let us know if JKI is has decided to stop new development, bug fixes and enhancements for VIPM. Thanks & Regards, James
-
Un-Publish/Deprecate vs. Install Other Version
James@Work replied to James@Work's topic in VI Package Manager (VIPM)
I hadn't worked on this issue until today and found I need data for the Post-Install custom Action.vi Is the Package Version available in the Variant data? If not, is there a way to get this information programmatically? Thanks for any suggestions. James -
Un-Publish/Deprecate vs. Install Other Version
James@Work replied to James@Work's topic in VI Package Manager (VIPM)
Jim, I don't have that option checked, however, that wouldn't correct the issue I am trying to address. If I Un-Publish or Deprecate a package from the Repository Manager I would expect that end users would not be able to use or re-install that package. However, since the right-click menu (list of packages) is built from package versions in the cache directory, any packages they have previously installed remain visible and can be re-installed from the cached copy. So, if I have a package version that had a critical bug, I cannot make certain that it is no longer used by simply using -
When I un-publish or deprecate a package I would expect that it would not be visible to the end users to select for install. However, after first trying deprecate and then Un-Publish I learned that they are all still on the list of "Install Other Version" found by right-clicking on a package. Even worse, I learned that these packages (Un-Publish & Deprecate) are all still available to the user since copies remain in the ProgramData (C:\ProgramData\JKI\VIPM\cache) directory. So, I need recommendations on the best practice to remove these (Un-Published & Deprecated) versions from t
-
OK, Thanks Ashish. However, it's bad that VIPM returns "Your software is up to date" dialog if the check were blocked by a firewall.
-
James@Work started following VI Package Manager (VIPM)
-
I was fighting a bug related to a problem that had already been corrected, but didn't realize I didn't have the latest version installed because Check for VIPM Update reports I have the latest version. Installed version: 2014.0.0 (build 1941) Apr 22 2014 Available at JKI: 2014.0.1 (build 1967) Oct 10 2014 Is there a bug with the process of checking for updates or has this release not been made public. I wasted a lot of time this morning before I realized the problem and downloaded/installed the latest release. Regards, James R. Jones
-
Ashish, I wanted to let you know the issue I encountered was NOT with my version of VIPM, but related to my use of sub-VIs in my Post-Build VI. In addition, I modified my process to use a Post-Install action instead of the Post-Build to acheive the desired functionality. I didn't upgrade my Package Manager as I assumed it was related to my process or VIs; it just took a while to isolate the root cause of my issue. Thanks for the feedback that gave me the confidence to find MY programming error. Regards, James
-
This is my first attempt to use a Post-Build Custom Action 1) I used the Generate VI button to create the shell VI 2) I added some very simple code to find/set a VI attribute to read-only During the build I received this error and don't know what to do next? " Error 15 occurred during the Build: Post-Build step. Possible Reason(s): (Script VI could not be opened) 13967F6905F236670976AD1488E1267A in VIPB_API.BuildAndPackageLibraryFromSpec[Private].vi " Any suggestions would be appreciated. Regards, James VIPM 2014.0.0 (build 1941) Apr 22 2014 Email me