Jump to content

Jim Kring

JKI Team
  • Content Count

    1,737
  • Joined

  • Last visited

  • Days Won

    43

Jim Kring last won the day on July 20

Jim Kring had the most liked content!

Community Reputation

80 Excellent

6 Followers

About Jim Kring

Recent Profile Visitors

26,529 profile views
  1. Hi there. Hmmm, there are several possibilities. 1) Remove the external package dependency (in VI Package Builder >> Dependencies setting) You can make a package an *internal* dependency in the VI Package Builder (go to the dependencies page and remove it from the list of dependencies, and then VIPM will transparently build those VIs into your distributed package) 2) If the VIs in that library are kept beneath your VI Package Source Folder, then VI Package Builder should build them into your package. You'll want to be sure they get "namespaced" differently (by renaming the lvlib or putting the lvlib inside another lvlib for your tool) so that the library's VIs don't collide with an installed version of that library on the end user's development machine. 3) Also, I see there are newer versions of this tool available and one is available in VIPM. - Tree-API << this is a VI Package, but I don't think it's hosted on vipm.io - Tree Map << this is the newest and *is* available on vipm.io for installation with VIPM Would upgrading to use the Tree Map work for you? Then you could just make this a dependency that your end users will be able to install.
  2. Hi @felipefoz. You can use the VIPM API to query this.
  3. Hi There. I think you may need to also (separately) publish the system package to the repository, too, in order for it to be correctly downloaded/found by repository clients. Please try that, and let me know if that resolves the issues for the clients.
  4. Hi @Rami_Saaidi, We've had another user report a similar issue recently. Have you tried re-running the installer after the error, to see if it works the second time? Also, I think one user said they resolved the issue by installing .NET 4.0 before running the VIPM installer. -Jim
  5. @Ruslan. Thanks for reporting this. Do you know if this also happens in newer versions of LabVIEW, too (e.g. LV 2020)?
  6. I see. Could you change your individual packages (that require none of their VIs are in memory) to require that LabVIEW be closed before installing?
  7. Hi @ranjgith. No, there's no such feature for VI Package Configuration files. Packages, themselves, have such features but not VIPC files. Can you explain a little bit about what you need to accomplish? What's your use case? -Jim
  8. Hi @wolfkil. Thanks for letting us know it worked for you. We're trying hard to keep things working well. Please let us know if you have any more issues.
  9. Hi @Olivier Jourdan. I have no idea why this setting wouldn't work. Can you try it on a super simple project to see if it's reproducible? If you can reproduce it and zip up the sample project, we can take a look.
  10. Fantastic! Thanks for lettings us know.
  11. @mprantl Install stats are shown in VIPM 2020's VIPM Browser and on the package pages of vipm.io
  12. This is available in VIPM 2020 available for download: vipm.io/download
  13. @sblades this is fixed (we hope) in VIPM 2020.1 now available for download: vipm.io/download
  14. @StefanLemmens - this feature is in VIPM 2020.1 which is now available for download: vipm.io/download
×
×
  • Create New...

Important Information

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