Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


hooovahh last won the day on February 10 2020

hooovahh had the most liked content!

Community Reputation

8 Neutral

1 Follower

Recent Profile Visitors

4,488 profile views
  1. Okay so personally I've come to the conclusion that I won't be using suffix or prefix anymore. If you are going to use renaming, use suffix. Prefix makes viewing all files sorted by name do unexpected things if it is mixed with files that aren't renamed. I also sometimes type the name of the function I'm looking for in Windows and if you add a prefix now you need to type "hooovahh_" before everything. So we've already mentioned reasons to not use suffix renaming. QuickDrop, Right click, and other NI frameworks rely on some naming conventions sometimes and these break. OO override iss
  2. I always defaulted to using the renaming, and only turned it off in rare cases when renaming broke things. So for me on those rare occasions where I didn't rename, things did work fine. I've been pretty mindful of cross linking and avoiding it between source and install. Given that the only major reason to use rename is to avoid cross-linking I'm going to try to undertake a change to have everything non-renamed. I want to be consistent one way or the other and it seems there are cases when renaming breaks things, but I'm unaware of any case when not renaming breaks things (other than cross
  3. So way back in the day (VIPM 1.x, 2.x) renaming of the source files in a build was required to build a package. The build process required that the built package would have VIs that had a prefix/suffix added. So a VI named "Do Super Cool Stuff.vi" would have to become something like "Do Super Cool Stuff_Hooovahh.vi". Because of this I've just continued to add a suffix or prefix to all my source VIs for all packages I've built. However I've ran into problems where the renaming might break things, or cause weirdness. So in some cases like QuickDrop Plugins, or Tools Menu items, I've tur
  4. I too would be interested in a way to make this work in an automated way. But until then one thing that might help make less steps, is making a VIPC with all the packages you want contained in it. Then on the new machine, after installing all things NI, you can double click that VIPC file, it will open it in VIPM, and ask what version to install them in, and then it installs all the packages at once. It still is a manual process but you don't have to select packages from a list, or be connected to the internet.
  5. I have a build that crashes LabVIEW with an access violation, and then VIPM gets an error. The build is attached. What the problem is, is that in there is a class, and that class is renamed during the build process adding the suffix "_hooovahh". But in that package is also a demo VI named "Defined Slider Test.vi" which uses a property node on that class. I've found that if I build, with the demo VI having a property node, linked to the existing class name, that during the build a rename takes place and crashes LabVIEW. If I disable the rename it builds properly, and if I enable
  6. The period folder is auto generated by VIPM during the build process. This is a temporary location where all files are copied to and processed. During the build this path exists and has the files in it. After the build fails (or finishes) it will cleanup that folder.
  7. Can someone from JKI tell me why this package doesn't build? It is relatively simple with no Pre/Post VIs, no file renaming, only a functions palette. But there are some XNodes and they are going into the vi.lib. On attempting to build it gives the following error: During the build I navigated to those folders and they exist and the files are there. If I remove that one XNode and its support files it builds properly. If I add it back with the support files it fails to build. I've tried mass compiling, resaving, and renaming VIs but it still errors. If I delete all other XNodes,
  8. I guess alternatively the Pre/Post VIs could be placed somewhere under the package source, so they are scanned. However for me I use the same Pre/Post VI for multiple packages and it is stored in a folder that isn't shared by any package. Thanks Jim.
  9. If there is a dependency added to a Pre/Post Install/Uninstall VI, this dependency isn't detected by the Scan for Dependencies function. Attached is a package that has a single VI that doesn't do much. But the package has a Pre-Uninstall VI that has a dependency on an OpenG Wait. Scanning for dependencies doesn't find any and I suspect it is because the Pre-Uninstall VI isn't part of the package source. The reason I want this is because my Pre/Post Install/Uninstall VIs are getting large and I wanted to make subVIs but they aren't brought into the package, only the top level. My work arou
  10. Well I was just able to uninstall and reinstall that package with 2016 32-bit Windows 7 x64. What version of VIPM are you using? I'd expect every version to be compatible with OpenG. Do other packages install alright in 2016?
  11. Update from JKI: This issue is planned to been fixed in VIPM 2018. So I can successfully build packages with VIMs in them. But I found that if I need to make a package, that depends on a package, which contains a VIM, the build will fail. First install the hooovahh_array_vims- package. Then try to build the File IO package, which at the moment only contains one VI. If it is like my setup the build will fail with this error. If I remove the VIM dependency by replacing it with the OpenG one the build is successful. Build Fail VIM Dependency.z
  12. So on VIPM 2017.0.0f1 I'm having a build that fails if I have some specific VIM, and the Renaming Convention is set. If I don't have renaming, or if I don't include this one VIM then things seem to work properly. Here is the error And attached is the source and build spec. If the Filter 1D Array-VIM.vim is removed from the source, then the build works (renaming all the other files to have _Hooovahh as a suffix). Or if the Filter VIM is left but renaming is disabled the build is successful. Array.zip
  13. The recently posted update VIPM 2017 F1 fixes this issue for me. Finally I can build all the VIM packages I've been wanting to.
  14. I found that if you go to the main download page and enter your email address it will start the download for version 2017 of VIPM. Even though the page still says the version is 2016.
  • Create New...

Important Information

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