Jump to content

Jim Kring

JKI Team
  • Posts

    2,021
  • Joined

  • Last visited

  • Days Won

    77

Everything posted by Jim Kring

  1. Hi Anthony, There was an issue in older LabVIEW versions (~LV8.x) where it had to save class Dynamic Dispatch methods into separate folders. In newer LabVIEW versions, there's an option to do the same thing. Perhaps that option is set to TRUE in your build settings. Try setting it to FALSE and see if it fixes the issue.
  2. That button/form is for publishing open source packages to the VIPM community repository. Some of the packages on VIPM.io are hosted on the NI tools network repository. You’re right that those buttons should probably be disabled for commercial packages hosted on the NI tools network.
  3. I think I see what you're saying -- if an older version of the package is published in a repository, but the installed/latest (i.e. displayed) version is not published, it would be helpful to know that it's a development version that's not yet "officially" published to the repo. This is different, perhaps, than a package where no versions are published. Idea: Maybe VIPM should display "Local" as the Repository name if no versions of the package are published. This deserves some more thought, for sure. I'm glad you have a workable solution, for now. Thanks for sharing these ideas. P.S. Yes, there have been some dragon signings lately
  4. Hi Laurent, Can you look in your error log folder to see if there's anything helpful in there? C:\ProgramData\JKI\VIPM\error Thanks for your patience and help debugging this. -Jim
  5. Hi @kosist. I agree that it's important to know if a package is not published. Right now, I think you can tell by looking at the "Repository" column and it should say "Unpublished" (as shown in the screenshot below). Is there somewhere else you'd like to see this "Unpublished" status more prominently?
  6. You're welcome @kosist and please keep sharing your ideas! It's a big help to the community
  7. This can happen if Windows Update is installing stuff behind the scenes. Is this a corporate IT controlled computer? Please try again after a while and see if that helps. Also, can you try uninstalling VIPM 2020.2 from Windows Add/Remove Programs?
  8. Updating this thread with an example post-install custom action that modifies Call Library Function Node paths. Example File: Post-Install Custom Action.vi Screenshot:
  9. Thanks for posting this great idea. Since it was a simple fix, we went ahead and made the change. Please try it out and let us know how it works for you.
  10. OK, great! Glad you were able to get the latest version. The latest version should hopefully also fix the issue with Check for Updates on Mac. Likewise, thanks a bunch. -Jim
  11. It's a good question. VIPM 2017 works with LabVIEW 2017 and older. So, you need VIPM 2020 to install packages into LabVIEW 2020. We don't have a VIPM 2020 for Linux, yet. What a lot of people do as a work-around is install LabVIEW 2017 on Linux, use VIPM 2017 to install the packages, and then copy them over to LabVIEW 2018-2020. Another, similar, approach is to install the packages on Windows or Mac machine and then copy them over to Linux. Thanks for your patience and understanding on this.
  12. Yes, a basic CI integration would be to know if any tests fail and abort the build. More advanced would be to output a results.xml file and have the CI system give details on which tests are failing.
  13. Might be good to make that VI public. FYI: @Francois Normandin
  14. Here's a pre-release of a build you can test. vipm-20.3.2540-windows-setup.exe PS - this link may stop working after a day or two, as we're working on the official release.
  15. Hmmm, OK. Thanks for that info and the kind words. It’s helpful. Fix coming soon.
  16. Oh, I think I know what it is. The service that auto-starts VIPM looks for the transition from NO LabVIEW versions running to ANY LabVIEW version running. Here's what I think happened: LV2019 started, which auto-started VIPM. VIPM was closed and LV2019 was left running. Then, LV2020 was opened (while LV2019 was still running) VIPM did not auto-start because the transition from NO LabVIEW running to ANY LabVIEW running did not occur. Anyhow, it's not super important, since we'll fix this, but I hope it's helpful to make sense of what was happening.
  17. Yes, that *is* odd. Question: Are LV2019 and LV2020 32-bit or 64-bit?
  18. Great. Yes, that should work too. I think you discovered a bug. When the System Tray is disabled, VIPM should not start up automatically when LabVIEW starts, even if Start VIPM when LabVIEW starts? is set to TRUE. We'll fix that in the next release. Glad you figured out a good solution.
  19. After you Disable System Tray in the VIPM Options, please reboot your computer and see if that fixes it.
  20. This sure is an odd issue, @nriver. Thanks for posting a link to the fix.
  21. Hi there. We've got a new build for Mac available here: vipm.io/desktop Please try it out and see if it helps with this issue.
  22. Hi there. Glad you got it working. I'm not familiar with the PATCH method. Also, the source is available on GitHub if you want to try supporting this. https://github.com/JKISoftware/JKI-HTTP-REST-Client Let me know if you have questions.
  23. Hey Greg. There's a new build (2020.3.2540) released. You should be able to get it via Help >> Check for VIPM Updates or the Updates Available button on the toolbar after a restart. Or, you can go to vipm.io/desktop
  24. Hi there. A couple things: 1) There is a way to disable this in the settings file. 2) We just released 2020.3 (SP3) that disables the system tray by default, which will also prevent automatic start when LabVIEW starts. My suggestion would be to go with #2 so you're running the latest and greatest version of VIPM, since it has some other improvements, too. Please let us know how that works for you. -Jim
×
×
  • Create New...

Important Information

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