Jim Kring

We're excited to announce the VIPM 2021 beta! You can Download VIPM 2021 Beta Software Here. Note: If you are a JKI Dragon Beta Tester, installing VIPM 2021 beta will remove JKI Dragon. Please do not install VIPM 2021 beta on the same machine on which you wish to continue testing JKI Dragon. What's New: Supports LabVIEW 2021 beta Main UI layout and usability improvements [build 2732] Fix - Installing packages with deep recursion (e.g. A>B>C>A) was getting stuck and hanging VIPM (e.g. SQLite toolkit). This has been fixed. [build 2732] Fix - Detection of project LabVIEW version was not working well if there were no VIs in project. This has been fixed and the LabVIEW version will be read from the .lvproj file. [build 2732] Fix - Missing Friend Classes No Longer Cause Package Build Errors - The package builder was raising a dependency missing error if a friend class could not be found. However, friends are not actually required. Now they don't cause a missing dependencies error. [build 2732] Fix - Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog [build 2732] Fix - Community Edition was not setting the "Restart LabVIEW After Install" flag in built packages (and other Pro features that are available to Community Edition such as pre- and post-build custom actions) And more...

Hi Jason, I'm glad you got it working. I'm curious if the problem re-appears if you upgrade back to 2020.3, but I'll let you decide when you have the time do that experiment. Thanks again for posting about this issue -- it's helpful to us and other users. Regards,

Thanks for reporting this, Patrick. It's a bug. Were you able to get the project installed successfully in your project's virtual environment via the classic VIPM Main UI? Kind regards, Jim

Hi @Jason Herington. Thanks for reporting this. I haven't seen this specific error before. Does it happen every time? -Jim

Hi Patrick, Thanks for reporting this -- this is a bug. You're right that if the packages exist only inside the VIPC file, then Dragon gets stuck trying to install the dependencies. Would you be able to share that VIPC file, so I can test it a little easier on this end? Thanks.

Can you try typing this into a terminal? cd ~/Library/PreferencePanes/ This will navigate you into the PreferencePanes folder then type the following: ls This should list the contents of the folder. Do you see something like the following? VI Package Manager.prefPane If so, then typing the following may fix the issue (as described here) by removing the "quarantine" flag in the OS security settings: sudo xattr -d -r -s com.apple.quarantine "~/Library/PreferencePanes/VI Package Manager.prefPane"

Hi Glen, Sorry for the frustration. Mac support has been challenging for VIPM, but we try. It looks from your post that you tried all the tips mentioned on the knowledge base entry here: File Permission Errors running VIPM on macOS The "AppTranslocation" thing in the file path ("/private/var/folders/w7/rtz9k1m114390vq0fxc21bv00000gn/T/AppTranslocation/54274253-33FC-46D0-A566-B7 F86CC7D1F7/d/VI Package Manager.app/support/callbacks.llb/Refresh Menus 2013.vi") makes me curious if this is some new kind of file system thing that we're not handling. I did some googling of "AppTranslocation" and found a couple interesting reads here and here. I'm not sure right this second how to fix this, but we'll look into if. If you're able to figure out a solution, please post back here.

Oh no! I’m sorry to hear the installers and security challenges are such a pain. I wonder if there’s a way to have a VIPM installer that does not include the runtime engine stuff — can you install VIPM and the skip over the runtime installer part, I wonder.

Yes, that would be the idea -- the flag would simply tell VIPM that global installation is required and the package cannot be installed into a virtual environment. So, if the package is not being installed by Dragon into a virtual environment, then it will be effectively ignored.

Great question! They have to have a VIPM.io user account and have their gitlab/github usernames added in their VIPM.io profile.

Thanks. We've seen this before. It's an issue with the curly quotes not working in the updates information file.

Thanks for reporting this, @Tom Law. Restarting LabVIEW 3-4 times seems like it could be a glitch/bug. I'll keep an eye out and if you can reproduce this, please let me know the steps.

Hi @Mariano Aristu, @kosist, @Steven Dusing. Thanks for the great idea and discussion. You're right that it needs to be easier for end users of packages to install packages and have them end up in the right (global vs local) locations. We're considering the options, which include the one's you've mentioned: A.) A setting inside the package (Pros: the package builder knows best and has more control, relatively simple to implement; Cons: requires rebuilding and redistributing the package) B.) Making VIPM smarter so that it can tell by looking at the package contents and where things are installed (Pros: would "just work" without having to rebuild packages or add more meta info to the repositories, Cons: Requires a lot of dynamic package contents/rules checking to determine where packages can/should be installed) C.) Making the repository aware of the setting for the package, so that packages do not need to be rebuilt (Pros: Doesn't require rebuilding packages, doesn't require smarts in VIPM; Cons: Requires extending the repo format and VIPM to use it, requires someone other than the package developer to define this setting, doesn't work for users who are off-line and don't have access to the repository). Based on this, it seems like option (A) adding a flag/setting in the package builder is a good one and also is compatible with (B) adding more smarts to VIPM in the future. Another other options or thoughts around this?

Good catch, Tom. We've certainly overloaded this dialog. Since the dialog allows you to choose existing (.lvproj, folder, or .dragon) files or a new .dragon file, I think that's why the button says "Save". We'll look at whether this can be simplified/improved. Thanks!

Hi Zachary, Can you try opening the VIPM Main window and refreshing the package list? 1) Click on the orange "VI" in the upper left corder of the window in your screenshot 2) Click the refresh button 3) Search for DCAF CVT

The package's homepage on vipm.io has a direct download button. Does that work for you? https://www.vipm.io/package/ni_lib_dcaf_cvt/

Hi Iker, I think that the problem is the window is off screen. Can you try closing the project, changing your screen resolution, and re-opening the project? We'll see if we can figure out a better fix for this. -Jim

Thanks for that info. Just to be clear: Is this a separate issue or does changing to "UTF-8 without signature" fix the original issue?

Thanks for the update. I haven't looked into it deeply, but I found a couple links that seem informative: https://stackoverflow.com/questions/10715001/bstr-to-cstring-conversion-for-arabic-text http://www.delphigroups.info/2/f5/481372.html If you're able to figure this out, it would be a great improvement to the library.

Thanks for clarifying all the different things you’ve tried. I’m sorry that the instructions aren’t working correctly for Arabic. I don’t have any experience getting this tool working for Arabic, so I haven’t run up against this problem. I’ll ask some of my colleagues if they know anything about it

I haven't tried, but I would assume that it already is compatible with Arabic. There's a documentation guide here to help you out: https://github.com/JKISoftware/JKI-Simple-Localization/wiki Please let us know how this works for you.

I've split this off into it's own topic...

Actually, never mind -- it's reproduce on our end, if running the built EXE application. It's just not reproducible when running Dragon from source code. We'll dig into it more...

Hmmm, that *is* strange. I'm curious... Is this always reproducible? On other systems? Are you working in a multi-monitor environment? Are you working in a virtual machine?

Thanks. I've split this into its own topic to track it as a separate bug.