Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 11/01/2020 in all areas

  1. Hi, I would like to ask for a help with the following issue: I am trying to distribute VIP file with some dependencies, which are not published on VIPM. Hence, I added them to VIPC and would like to distribute this VIPC with VIP file. Is this somehow possible?
    2 points
  2. 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
    2 points
  3. Thank you @Jim Kring for the KB and for the suggested workarounds. We were considering the option of adding toolkit directly to source, but then decided simply to get rid of it completely since we've used it just as simple DVR-based lookup table. Moving to Tree Map was not possible, because it supports LabVIEW 2019 and later, but our project is done in LabVIEW 2015...
    1 point
  4. I'm trying (and failing) to build a package for my Y Controls. When I run the VIPB file, sometimes it aborts claiming that a file or files are missing; but the files aren't actually missing and they aren't dependencies of Y Controls. Sometimes when I run it, I get no errors, but also no output. I would appreciate any suggestions. Y Controls.zip
    1 point
  5. Hi again, Ivan. I went ahead and created a new Knowledge Base entry for this issue, since many others have experienced this error message: Error 1357 during a package build (File Already Exists) Let me know if that makes sense and/or if I missed anything (other possible workarounds or made any misstatements in the recommended workarounds).
    1 point
  6. 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
    1 point
  7. Just the idea - not sure whether it is possible to implement. There are some packages, which are used as dependencies in other packages. And, we can find dependencies of the packages by sending package to configuration; but we can not find packages which are dependent on some particular packages. If we could do something like right click on the package in the list -> Find dependent packages, and it would show us list of packages (ideally even not installed) which use that package as dependency, that could be sometimes useful. Now, for example, we use some package as dependenc
    1 point
  8. How can I download a package off of VIPM.io so that I can transfer it to a non networked computer for install? I can’t find a way to download it. It just wants to invoke the VIPM application to do the install. I’m downloading on a computer that doesn’t and can’t have the VIPM application installed.
    1 point
  9. Jim, Thank you. Your first answer wouldn't work in my use case as we don't have permission to install VIPM on the internet enabled computer. However, your second answer is exactly what I needed. I need to be able to download the package, burn it to disk, and sneaker-net it to the development (not internet connected) network. I'm off for Thanksgiving but I'll give it a test when I'm back at work. It lets me download a package at home so it looks like it will work for me. Thank you for the quick turn around! --Q
    1 point
  10. 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!
    1 point
  11. @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 app
    1 point
  12. We've implemented the following solution. One Drive is mapped to the same location on all PCs (Public Documents), and we have shared one folder as repository folder. So we could publish packages to that location from any PC, and scan it as VIPM repository. Thank you for your help, Sincerely, Ivan.
    1 point
  13. 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.
    1 point
  14. Thank you very much! I've already tried that (added URL directly to ini file) but it didn't help. I guess there is really issue with Dropbox. Most probably we would do the following - add OneDrive (or Dropbox) folder to the same locations on all our PCs, and then treat them as local repositories...
    1 point
  15. 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
    1 point
  16. 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.
    1 point
  17. 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
    1 point
  18. If I use some of the Boolean designs on a GUI for a company I am contracting for does the company have to pay a license for use? I am changing some of the look of the Boolean control.
    1 point
  19. Some advanced users are asking for support to install VIPM for Windows onto a Docker container. This would allow creating fully automated build processes that spin up virtual machines that have LabVIEW and VIPM installed on them, so that VI Packages can be created automatically.
    1 point
  20. It would be useful for quickly building palettes if the file dialog that appears after selecting the Add Control or VI option allowed multiple files to be selected. This would be especially useful if a folder contains a mix of CTLs and VIs, or a mix of items that are wanted on the palette and ones that are not.
    1 point
  21. For Windows: LVRunTimeEng.exe (see here for detailed installation instructions) For Mac OS X: LabVIEW821RuntimeEngine.dmg (see here for detailed installation instructions) For Linux: labview82-rte-8.2.1-1.i386.rpm (see here for detailed installation instructions) labview-rte-aal-1.1-1.i386.rpm Linux Installation Instructions (more info here): Run (must be logged in with root access for the machine) rpm -Uvh labview-rte-aal-1.1-1.i386.rpm Run (must be logged in with root access for the machine) rpm -Uvh labview82-rte-8.2.1-1.i386.rpm If the above links do not work then
    1 point
×
×
  • Create New...

Important Information

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