Jim Kring

@Paul Cardinale, Quick update: We've changed the forum software so that it allows sign in with either the Display Name or Email Address. Hope that helps.

Hi Paul (@Paul Cardinale) Thanks for all the honest feedback. I'm sorry there have been so many problems -- I can see it's frustrating, and I'll do my best to help. > I fixed the missing files problem, but now I get error 1357. I'm glad missing files problem is resolved. Thanks for reporting that. We've created a knowledge base entry for it and have already fixed the issue in VIPM 2020 SP3 which should be released soon -- let me know if you'd like to try it out early. Regarding error 1357, @kosist just posted something similar and I replied with a work-around and just created a knowledge base entry describing the issue and work-arounds. Basically, the issue is that each lvclass should be put into its own custom destination if it contains VIs with same names (such as dynamic dispatch method VIs). > Furthermore, dealing with your website is about as pleasant as removing lug nuts with my teeth. > It always rejects my login. The only way I can get it is to reset my password. But then the next time I try to login, it rejects me again. I've seen this before. When you sign in to the discussion forums, you need to user your display name "Paul Cardinale" as your username (not your email address). This has caused many people a lot of confusion, because it's not very intuitive. > (Also, your anti-robot feature is awfully annoying.) Totally. At some point I think computers are going to outsmart us all. Yet, we continue to make them smarter... > And to top it all off, your "Contact Us" link always leads to "Page Not Found". Oh, OK. Which page has the broken "contact us" link? I've just poked around and I can't seem to find the broken link. > Your product is broken. Your website is broken. Your contact link is broken. How on Earth do you stay in business? It makes sense you're frustrated. To answer your question literally, it's hard to stay in business developing and providing technical support for a free product (VIPM Free and VIPM Community Editions). There is a paid/professional version of VIPM Pro for teams with a lot of great features, and JKI also offer consulting services and training around LabVIEW.' Also, we're very interested to learn more about the problems and fix them, so thanks for not giving up. We'll do our best to get you going...

Hi Ivan, You're right: Error 1357 during a package build generally occurs when two VIs of the same filename (but in different lvclass'es or lvlib's) are targeted into the same folder during the build. Fortunately, if the classes/libs (with the same-named method VIs) are stored underneath your VI Package's source folder then you can create a custom destination folder for each of them (and target each lvclass/lvlib with it's own specific destination folder). So, maybe you could move the Tree API into your project source folder. Then, you can have more subtle control over choosing specific destinations for each of its classes. I see that the Tree API is distributed as both a VIP and a ZIP file. Maybe you could just extract the zip into your project folder. Also, you might want to rename the root level Tree API.lvlib to something like "TREE API__MYPROJECT.lvlib" so that there will not be a name collision if the packaged version of the Tree API is also installed. Also, I see that there's a newer Tree Map library which *is* published in VIPM. I'm not sure what it would take (or whether it's possible) to upgrade from the Tree API to the Tree Map -- I haven't used either of those libraries yet. Yet, maybe that's another option. Note: this approach with custom destinations will not work for internalized package dependencies, since package dependencies are installed underneath the LabVIEW folder and only files saved under the project source folder are shown in the source file settings view in the VI package builder. Said differently: files located under the <LabVIEW> folder cannot be targeted to a custom destination -- it only works for files stored under the VI Package's source folder. The solution then, is to move those dependencies into the project source folder, as described above. Hope one of those possibilities works for you and thanks for the feedback. You're right that it would be great if there was VI name collision detection in the package builder and it could save the colliding files into different folders automatically.

Thanks for sharing your thoughts on this, Ivan. I agree that this is a helpful use case. I think there are a couple aspects to this: 1) For a potential user of a package to know if other people are using the package -- this adds some credibility that others trust it and likely indicates some level of expected quality. 2) For a developer/publisher of a package to understand who the users (dependency project) are, to possibly understand how people are using it and what possible impacts changes to a package might have. I like the idea of supporting this (I would surely use it), and I wonder how users would find value in it. Let's see how many votes/comments it gets

Great! Im glad this looks like it’ll work for you, Quentin. Hope you have a fantastic Thanksgiving and looking forward to hearing how this works for you when you’re back to work. Jim

Hi Again. Update: To make this easier for you and other users, we've updated the package details page with a "Download Package" button, as shown below. Please let me know how that works for you, and thanks again for the great question/feedback!

Hi Quentin, Thanks for your good question. Here's a how to guide for that use case: How do I transfer packages with VIPM to a non-networked computer? Note: This requires VIPM Community Edition or VIPM Pro to create a VIPC file that stores a copy of the package inside the VIPC file. Would that work for you? I understand this isn't exactly what you asked for. -Jim PS - thanks for your patience, since many of us our out on thanksgiving vacation this week.

Thanks, Ivan. We've gone ahead and posted a knowledge base How-to arg about this: How to create a package repository with DropBox, OneDrive, Box.com, Google Drive, etc. (for sharing packages)

This is a great idea @kosist -- yes, it would be nice to know which packages declare a package as a dependency without having to open them up individually. I'm curious how you might use this feature. Can you explain a little bit more about what sort of programming or project-management problems you might solve with this? I can think of some (that I'm happy to share), yet I'm curious to hear what you think, before I bias the conversation

Hi @Paul Cardinale We've had some success reproducing and isolating the issue. Knowledge Base: [18867] VI Packages cannot be built if their hierarchy contains VIs stored under the LabVIEW\help folder (results in Missing VIs error) There's a potential workaround (see the KB entry above) and also this should be fixed in VIPM 2020.3, which will be released soon. Let me know if you'd like to help test 2020.3. -Jim

PS - When VIPM process is still in memory, it may be the case that the VIPM System Tray (show below) is running. When the System Tray is running, the "VI Package Manager.exe" process stays in memory and opens faster when VIP and other files are double-clicked. However, some users (like you) have reported issues with this not working well for them. The new 2020 SP3 aims to fix this.

Hi @turbophil. Thanks for reporting this and sorry for the troubles. Some thoughts and ideas: 1) If the Error 8 issue is happening as a result of files in the cache folder (C:\ProgramData\JKI\VIPM\cache), then the best solution seems to be deleting those files. Please see this Knowledge Base entry. [18852] Cannot Install Package (Error 8: Open/Create/Replace File related to a package spec file) 2) We've been working on the issue with the VIPM process staying in memory. Please check if you're using the latest public build, since that has some fixes that have helped other users. 3) We have a 2020 SP3 (2020.3) that we're working on that may resolve your issue. If you're interested in helping us test this, let me know. Thanks again for your patience and taking the time to document what's been working and not. Hopefully, we'll get this working for you. -Jim

Hi again, Paul. I just tried building the Y Controls and I got this error about missing VIs -- is this what you're seeing, too? I'm going to dive into it a little further...

Hi @Paul Cardinale. Thanks for reporting this. Can you check your error logs folder to see if there's anything useful in there (the file will have the date in the filename)? C:\ProgramData\JKI\VIPM\error

@Vollinger: Great question! First, I was going to suggest the possibility of distributing a VIPC file (instead of a package) that includes your package and all it's dependencies inside of it. You can then name this VIPC file to convey that it's your package+dependencies. However, this approach doesn't fully look like an installer for your package -- it appears like a multi-package installer to your users. However, it's a pretty clean approach that involves distributing only a single file. And, you can name this VIPC file to convey that it's the installer for your product. Another approach is to build the dependencies into the package file (if you remove the dependencies, then the package builder will pull in copies of those VIs and namespace them such that they are internalized inside the package). This makes your package file larger, since it now includes the dependencies and you also have to consider the licensing terms of your dependencies. @James@Work: That's a very clever idea to putt a VIPC file inside the package as a support file. I'd love to hear how this works in practice. Some considerations with this approach that come to mind: - Dependencies are typically installed by VIPM before the package that depends upon them, and the package's installed contents are only available after the package is installed. So, the VIPC would need to be invoked *after* the package is installed (in a post install custom action). - This approach makes the package file larger (since the package contains its dependencies). - Some consideration may be needed about whether to install the bundled packages, if newer versions are already installed or happen to be cached/available. - Deadlock issues may occur if a post-install tries to invoke the VIPM API to install packages, synchronously (since a package would try to install packages, which require VIPM to be idle, but it's not idle, because it's installing a package).

You're welcome and I'm glad we were able to find and fix a bug in VIPM. BTW, I had a typo in my response to you. I meant to say "I think they changed it so that you can no longer serve static sites/files over HTTP." Yes, some users have found success in having DropBox/Google Drive/Box.com/OneDrive replicate the repository locally as a network hard drive or folder, and then have each VIPM client reference it as a local repository. Let me know how that works for you.

Hi @kosist Thanks for sharing this question and feedback. At one point this worked with Dropbox, but I think they changed it so that you can no longer serve static sites/files over HTTP. I'm not sure about OneDrive. Basically, you'll need something that can host all the repository files as a static website. Regarding the issue where VIPM changes URL to lower case letters: There's actually a work-around for this. You can add the URL and then fix it in the VIPM settings INI file, as described here: [18866] Package Repository URL is coerced to lowercase when adding (should preserve case when adding) Please let me know if you have any other questions about this or other ideas. Thanks, -Jim

Hi @James@Work. Thanks for posting about your experience with this. I'm sorry that JKI Design Palette was interfering with QuickDrop. Thanks for the good suggestion on including better documentation/instructions for how to work around this and for uninstalling it. I'm glad to hear it's working for you now.

@Sam Taggart, @StefanLemmens. We just published a new build of the VIPM API which should address this issue. https://www.vipm.io/package/jki_lib_vipm_api/#2020.0.0.65 2020.0.0.65 (Nov 17, 2020) This release adds support for VIPM 2020 (including Community Edition) and LabVIEW 2020, and also adds a few new features, changes and fixes: - [NEW] VIPM 2020 and Community Edition support (Community Edition can use API calls, just like Pro) - [NEW] LabVIEW 2020 support (fixes an issue where passing version 20.0 was failing a version check) - [CHANGE] Now compatible with LabVIEW 2013 and greater on Windows (was 2009 previously). - [NEW] API VI "Check is VIPM Running" will check if VIPM app (process) is running - [NEW] API VI "Open VIPM" will open the VIPM Main UI (and launch VIPM if needed) - [CHANGE] "Exit VIPM.vi" to run synchronously. It has a new "Timeout in seconds (0: no timeout)" input and waits on VIPM process to be fully exited. Also, has a "synchronous? (T)" input which can be set to FALSE if asynchronous behavior is desired. - [CHANGE] Separated compiled code from source code (All VIs) - [FIX] API will now return an error if VIPM process terminates (crashes) before a timeout occurs when calling a synchronous command.

Hi @JamesW. We just posted a new build of the VIPM API which should address this issue. https://www.vipm.io/package/jki_lib_vipm_api/#2020.0.0.65 2020.0.0.65 (Nov 17, 2020) This release adds support for VIPM 2020 (including Community Edition) and LabVIEW 2020, and also adds a few new features, changes and fixes: - [NEW] VIPM 2020 and Community Edition support (Community Edition can use API calls, just like Pro) - [NEW] LabVIEW 2020 support (fixes an issue where passing version 20.0 was failing a version check) - [CHANGE] Now compatible with LabVIEW 2013 and greater on Windows (was 2009 previously). - [NEW] API VI "Check is VIPM Running" will check if VIPM app (process) is running - [NEW] API VI "Open VIPM" will open the VIPM Main UI (and launch VIPM if needed) - [CHANGE] "Exit VIPM.vi" to run synchronously. It has a new "Timeout in seconds (0: no timeout)" input and waits on VIPM process to be fully exited. Also, has a "synchronous? (T)" input which can be set to FALSE if asynchronous behavior is desired. - [CHANGE] Separated compiled code from source code (All VIs) - [FIX] API will now return an error if VIPM process terminates (crashes) before a timeout occurs when calling a synchronous command.

Great suggestion, Steven, and one that we're looking into! It gets my vote.

Hey Steve, This is a great idea and has been on our mind, too. I'd love to see this feature in VIPM Desktop. In the meantime, (as shown in the screenshots below) you can see the linearized release notes on the package's homepage on vipm.io (for publicly released packages, of course -- that won't work for private packages in your or your company's own reuse library). Hope that helps a little and thanks for the great idea! You get my vote

Great question. Short answer: no, you don't have to pay anything to use them in your projects. Long answer: Please see the license info here: https://resources.jki.net/jki-flat-ui-controls-toolkit

We have an official bug ID for this 18825 - VIPM API doesn't handle LabVIEW 2020 We're working on a fix.

VIPM 2020 is available for Mac. https://support.vipm.io/hc/en-us/articles/360045837651-VIPM-2020-1-Release-Notes-Windows-and-Mac-