Jim Kring

@LavaBot - I can't speak directly for @nrosenberg, but from my experience, one of the challenges in creating applications is creating code that works in both the development environment (source code) AND in a built applications (exe). So, if Application Directory is used, then the path will point to the LabVIEW installation location when running from source code. So, we don't want to use that node/function when running code in development. Instead, we would probably want to test for whether the code is running in development or the build application and then build our path differently. However, simply putting our file in the folder next to wherever the VI is running (by using "Get Current VI's Parent Directory.vi") is an OK solution to this problem. Yet, in most larger applications that I see, a more specific solution is used, as to where files should be placed in development vs deployed environments, since there are often a lot of files and we generally want to organize them all a little bit better (under some base folder of settings), even in source mode (and not have a bunch of important files sitting next to VIs throughout our project source code folder).

I think that the error is in the use of "Current VI's Path". When you strip up one level in development mode (when the Current VI is directly in a folder) then you get the folder where the VI is located. For an EXE, the VI's path will be nested inside some virtual folders inside the EXE file. Try using the OpenG VI "Get Current VI's Parent Directory.vi" this is a bit smarter in terms of getting the actual OS folder where the VI/Code is located. You can call it like this -- both of these snippets are equivalent.

You can disable this feature as described earlier in this thread and here: VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up

Thanks for the head-up fab. I'm working to fix that

Hi Yair, Regarding the problems installing the package, can you check your error log folder? C:\ProgramData\JKI\VIPM\error Regarding older installer downloads: The main page listing the older versions is publicly visible (now), and the installer downloads themselves do require a sign-in. Thanks for your understanding about this. It does create a support burden to have legacy software in use (since new versions of OS'es, LabVIEW, and other software can break things), so it helps to limit legacy downloads to customers with legitimate needs. Putting a small hurdle of a sign-in (and a notice to appropriate support resources) helps in that regard, and also helps establish a communication channel to inform users of fixes, new versions, etc. We're doing our very best to produce a useful and high-quality application that meets the needs of 10's of thousands of users over time, and that's no small feat. Everyone's feedback here is totally valid, so thanks for sharing more about what's working and what still needs some love.

My recommendation would be to save the data to disk in the LabVIEW Data folder: <Documents>\LabVIEW Data\2019(32-bit) There really isn't a good way to retain data across Quick Drop calls unless you do something to keep a running process in memory behind the scenes, which is a big can of worms... Yair's solution looks great -- I wasn't aware of that nice feature!

Hi James. We fixed the link to the downloads page. Thanks again for reporting that and please let us know how it works for you -- your feedback is really helpful, as always.

Oh, thanks for letting me know. We'll fix that, right away.

The link vipm.io/download page is the official place to go -- there is a link on that page for people to obtain older versions of the installer. We're working to improve that page over the coming weeks, to make this process easier, so stay tuned. It sounds like you’ve got a copy of the VIPM 2019 installer and have everything you need at the moment -- if you or any other user needs a specific version you can’t find, please let us know via that link we provided. Thanks!

Great! I’m glad that worked for you, @Neil Pate.

Sorry about that @LogMAN. It should be publicly visible now. Please try again and let me know: VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up

I think I may have figured it out. When I looked at the drop-down selector for the "Following" options for this post, I noticed something for the first time. It appears to be a warning message that something is wrong with my notification settings. When I click that Notification Settings link, I get to this page and I notice that Email notifications for comments on my posts, appears to be turned OFF. I'm not sure how that happened. I changed it to TRUE and hopefully, I start getting emails again.

Hi @LogMAN and @Neil Pate. Thanks for letting me know. Actually, the reason I ask is because I want to be as responsive as I can to important threads on LAVA (e.g. that relate to VIPM, etc.), yet I don't seem to be getting an email notifications. This makes it very hard to do that, and might give the appearance that I'm less responsive than I want to be. Hoping we can figure this out...

I checked my email inbox and I haven't gotten any notification emails since ~October, 2019. I checked my spam folder. Anyone else not getting emails from lavag?

Thanks for the quick response @LogMAN No problem @LogMAN. I enjoy a good rant, as much as anyone 😛 I try not to take it personally when it's about VIPM (even though it's been a labor of love for ~20 years), and honor everyone's good intentions to make their development tools better, contribute to the community, and get their work done as effectively as possible. Those are really good points about how to make the VIPM system tray service more configurable in terms of opt-in/-out. Honestly, we were/are trying to take a lean (MVP) approach and listen to people's feedback. That's also hard for developer tools, where people do want access to the whole Swiss Army knife of settings. So, we did our best to at expose those to users via config file settings. This discussion has been helpful, and I've gone ahead and posted an official KnowledgeBase entry to make sure people can find this easily, in case the high-level features don't provide enough granularity. VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up Thanks again and keep the feedback coming! I'm glad to hear you're going to give VIPM 2020.1 a try.

Hi Everyone, I was just alerted to this discussion (thanks @drjdpowell), so I wanted to be sure I heard all the feedback, to make sure we're staying on top it. Before I dive in, I'll mention there is a version 2020.1 in beta right now (if you can't access this, please be sure you sign up for the beta and/or send me a PM). This addresses many of the points raised here, so please check it out. Also, it's important to mention that VIPM 2020 had a LOT of work (and love) put into it, and the beta+launch was in the middle of COVID-19, so things didn't get as many eyes (i.e. beta testers) as usual. That's unfortunate and we're working hard on the new 2020.1 build. Any feedback/issues you have are important, so please do post them and know we're listening. It's hard to keep tabs on conversations that happen in various LAVA threads, so if you'd like to see something improved/resolved, please do post it in the VIPM forum or PM me. I'll try hard to respond to the good points everyone raised. First, I'll mention that VIPM 2020.1 no longer requires a sign in when installing packages from the VIPM Community Repository. In 2020.0, this was causing issues for some users due to their Enterprise IT/Networking configuration. And, as you've all mentioned, some users really didn't like it, which is fair. There are still some features that use sign-in, like starring packages, and there will be a prompt when those features are invoked. @LogMAN Actually, nothing changed with how VIPM installs itself 2020, as compared to 2019 (and older versions). The issue was that the the VIPM 2020.0 (and older) installer framework (e.g. Advanced Installer) needed to be updated for newer versions of Windows. In VIPM 2020.1 (now in beta -- see link above) we've addressed this issue and it should install without issues. That said, there were some bugs in NI's LabVIEW 2020 installer that causes it to fail to correctly install VIPM 2020, in some cases -- e.g. the issue where it sometimes would fail to start. NI has been working with JKI to fix this. @Neil Pate That's fair We added this feature to make VIPM much more responsive when users are opening packages -- VIPM sometimes runs as a background task, so that it doesn't have to reload itself for each of these operations. This can be disabled in the VIPM settings file, here: "C:\ProgramData\JKI\VIPM\Settings.ini" [General] Start VIPM when computer starts?="FALSE" Start VIPM when LabVIEW starts?="FALSE" @Michael Aivaliotis Thanks for helping everyone out. Older versions of VIPM are available to users -- we have a link on the vipm.io/download page for users. However, since older versions of VIPM use outdated LV runtime engines that are longer be supported by NI and don't work well on newer OS'es, we don't encourage users to use them -- it often creates more problems for them, and a support burden for JKI and NI. As such, we ask that people do not post older downloads and instead direct people to get them from either NI or the VIPM websites. Again, thanks for helping people out. Also, I appreciate everyone's feedback -- I know when things don't work well, it's super frustrating. VIPM 2020 had some bugs and left room for improvement, because of all the new features that had to get out the door in time for the LabVIEW 2020 launch date, and we didn't have the typical level of beta testing. I hope 2020.1 resolves those, and if it's still missing things or not working right, let me know and I'll take responsibility for those issues. Kind Regards, -Jim

We should have a fix for that (firewall issue) out in the next week or so. Thanks for your patience.

Beta is now open: https://blog.jki.net/news/vipm-2020-for-macos-beta-sign-up-today

Hey @MikaelH. I can't seem to be able to create this on my system. Can you post a VI or a snippet of the above code? Thanks and wishing you well.

You can find out more and sign up here: https://forums.jki.net/topic/3082-vipm-2020-beta-sign-up-is-now-open/ here’s a teaser (below). Lots more exciting stuff to come...

VIPM 2020 Beta is now available - sign up here: https://forums.jki.net/topic/3082-vipm-2020-beta-sign-up-is-now-open/

Filed with NI R&D: Bug 974336

[Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.

We've been able to reproduce and fix this issue (ID 18605). It'll be fixed in VIPM 2020. You can follow this thread on JKI's forums.

I'll try not to repeat myself too much here, since I've already posted a response here. I do welcome participation in making OpenG better and the current repositories are open to issues/pull-requests/etc. I'm not in favor of a new GitHub repository at this moment, since there are several things I've had on the roadmap, including fixing the website issues.