Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. FYI, we've created Knowledge Base entry for this issue: VIPM 2020.1 Crashing on macOS 11 "Big Sur"
  2. Thanks for the update @pkeller. I'm glad we're over that hurdle. Does the same thing happen for other packages? Thanks for your patience. We don't have too many users/testers on Mac and the Big Sur changes have been pretty significant.
  3. @pkeller Can you try executing these two commands from the terminal? defaults write "VI Package Manager" NSGraphicsContextAllowOverRestore -bool YES defaults write "VI Package Manager" NSViewAllowsRootLayerBacking -bool NO I believe that this will make it so that VIPM can run i(similar to how the commands in my previous reply enable the LabVIEW IDE to run).
  4. Thanks for posting this @pkeller. There's been a lot of grief (in general and not just with LabVIEW) due to Big Sur, from what I'm hearing. Regarding that helpful discussion thread on the NI LabVIEW forum, did you try executing the suggested command lines into a terminal? defaults write com.ni.labview NSGraphicsContextAllowOverRestore -bool YES defaults write com.ni.labview NSViewAllowsRootLayerBacking -bool NO I'm wondering if you tried that and whether it helps to get VIPM running. I'll also ping NI to see if I can find out more... Thanks, -Jim
  5. OK, glad you found a work around (sort of). Sorry that VI Package builder couldn't handle that automatically.
  6. I think that what you’re seeing is the control is highlighted because the user is tabbing through the controls. This is built-in to all of labview’s controls. I think the only thing you can do is to configure the control to skip tabbing, but I’m not sure if you want to do that because some users really like to tab through controls with the keyboard instead of using the mouse.
  7. Another update: We created a new Knowledge Base entry for Error 1357 during a package build (File Already Exists) Let me know if that makes sense and/or if I missed anything.
  8. 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).
  9. @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.
  10. 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 cr
  11. 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
  12. 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
  13. 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
  14. 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!
  15. 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.
  16. 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)
  17. 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
  18. 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
  19. 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.
  20. 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
  21. 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...
  22. 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
  23. @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
  24. 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.
  • Create New...

Important Information

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