Jump to content

hooovahh

Members
  • Posts

    78
  • Joined

  • Last visited

  • Days Won

    4

hooovahh last won the day on February 10 2020

hooovahh had the most liked content!

1 Follower

Recent Profile Visitors

4,597 profile views

hooovahh's Achievements

Enthusiast

Enthusiast (6/14)

  • Conversation Starter Rare
  • Week One Done
  • One Month Later
  • One Year In
  • First Post Rare

Recent Badges

8

Reputation

  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 issues, you must have all children classes, in the same package as the parent class. Otherwise overrides won't work until it is installed. So a demo or example VI in the child class will be broken until it is installed if it uses the parents override. But I have another new reason. I had one package that was 16MB in size and was too big. So I moved a bunch of stuff into it's own package. Well the source expected to find all dependencies without the suffix name. Since it was previously in the same package. But now the functions it calls is in the installed location and the VI names aren't the same. It was looking for the VI names without the suffix, but now needs the VI names with it. This means replacing every VI, VIM, control, class, library, XControl, and every dependency. Scripting helps but still is a pain. If I was never using suffix naming then it would just look for the VI names and loading the installed VIs into memory first, would mean the new package finds the source in memory where I want and a Save All will update code to use the installed location. And I hope it is pretty obvious changing from using suffix, to not can be a major pain if your libraries are as large as some of mine are. This also means updating all active project, replacing all dependencies to the new ones...also painful. Jim is right that more consideration needs to be made when editing package source to make sure it links to the installed locations of other dependencies. But editing one package at a time can help with that. And I've seen VIPM gracefully fails to build if a dependency is outside of the source. Once built and tested all is good.
  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 linking which can be avoided). My major development woes with this is going to be having a VI that used to call something like: <user.lib>\_Hooovahh\<Package>\Name_hooovahh.vi is now going to have to be updated to point to the Name.vi instead. I have some scripting code to help with this which can return the expected missing VI path, but this doesn't seem to work for VIMs. I already posted over on NI's forums here. Until I get a solution it will be lots of manually fixing VIs and rebuilding...then fixing all the active projects.
  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 turned off the adding of the suffix and things work fine. I've also realized that if I have a package that contains a parent class, and I create a child class as a separate package, then I can't perform the rename, since overrides will be looking for the child class to have the suffix. So a parent VI of "Parent:Find Hardware_Hooovahh.vi" will look for an override with that name and not the source name of "Child:Find Hardware.vi". So with all this being said, should I perform the renaming at all? Should I go through all my reuse libraries and rebuild them all, removing the suffix? If I do that I'll likely need to write some scripting code to replace all the calls of the suffix with the one without. Is there any real benefit to having the rename when there are clearly draw backs? Thanks.
  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 the rename, but remove the property node in the demo VI, it also builds properly. I also found that if I add this demo VI to the class it renames properly which for now is a fine work around. Can this bug be addressed so that VIPM properly builds and renames the class, while not crashing LabVIEW if a property is linked to the class in another VI? Won't Build With Demo and Rename.zip
  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, and all other support leaving Common and the Compare to Constant, it also fails to build. Any help is appreciated. EDIT: LabVIEW 2018 SP1 F3 32-bit, VIPM 2018 0.0.f2, Windows 7 x64. XNodes Won't Build.zip
  8. 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.
  9. So...is anyone from JKI monitoring these forums? I have a show stopping bug that I posted two weeks ago, in the latest version of VIPM, can anyone give any advice? Thanks.
  10. Update: this issue has been fixed in VIPM 2017f1 I've been using the new VIMs feature of VIPM 2017 and am having some issues getting it to build successfully. If I have a VIM on the palette it builds just fine, but if I add a VI that calls that VIM the build fails, even if that VI isn't on the palette. Attached is a zip with my source. It fails to build because the normal VI "Is Variant Repository.vi" calls a VIM that is in that package. If I delete that VI the build works fine. Is this a known limitation that a package can't be built, if a VI calls a VIM? Here are the errors seen when the build fails. Thanks. Variant Repository Source 2017.zip
×
×
  • Create New...

Important Information

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