09-09-2021 09:43 AM - edited 09-09-2021 09:54 AM
Good morning,
Let me preface by saying I'm a stickler when it comes to my installers only installing the files my program needs to run.
I have a package called GPower installed via VIPM, it's got a few cool things. When I build an executable that uses certain VIs from that package, a Local Help File (Error_User_Guide.html) is automatically added into the data folder. I don't want that. What can I do to make sure it doesn't get added?
Things I'd rather not do but I guess I will if it's there's no better option: add a post-build action VI that gets rid of it after every build, remove the local help file from each and every GPower VI that has it.
Moreover, I guess I don't get why the Help File automatically gets added in the first place. I get that it's meant to help someone understand how to set up a VI and operate it normally and whatnot, but that's stuff that a developer needs to see, not a test technician. In what scenario would a user of a built application need to see a Help document for a specific VI? Anyone have thoughts on that?
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
Solved! Go to Solution.
09-09-2021 11:22 AM
Which VI's is it? Can you provide a minimum reproducable project file? I tried with a random GPower VI but it didn't seem to generate the Help file.
Also, is it happening when you build the Executable or when you build the Installer?
09-09-2021 11:58 AM
Adding any of the VIs in the Error & Warning palette should get it in there, but just in case I did make a bare min project file that reproduces it. Generating the preview of the build is sufficient to show it. This is all in 2017 SP1 32b, by the way.
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
09-09-2021
02:06 PM
- last edited on
09-11-2025
03:37 PM
by
Content Cleaner
I poked around, and apparently this is (sort of?) expected behavior. The VI's have the following setting in their VI Properties -> Documentation page:
Interestingly, the document regarding linking VI's to custom documentation (https://www.ni.com/docs/en-US/bundle/labview/page/linking-vis-to-custom-documentation.html) explicitly states "Note If you link from VIs to HTML files or compiled help files and you use the VIs to build a stand-alone application, you must include the files as source files when you build the application."
I would have expected that this meant it wouldn't be included if you didn't explicitly include it, but it appears it's being included anyway. I'm not sure why, but I believe this is what's going on.
I can think of a couple workarounds:
1: Pre-build action VI that removes the Help documentation from all VI's (or at least those which point to the offending .html file)... I think you said this one though.
2a: Explicitly include the html file in the build (open Dependencies, then the GPower Error library, right click->explore, it should be one level up from there in "docs" or thereabouts on your machine)
2b: Explicitly add the html file to the build, add a Destination of %temp%, and send the file there when it gets built. You may need to fiddle with the installer to make sure it either 1- doesn't copy it over or 2- copies it to the new computer's %temp% directory, where it'll be cleared out at some point.
PS: Apologies if you knew all this already. I didn't realize the Help docs for a VI existed once compiled, so this is all news to me.
09-10-2021 06:45 AM
2b doesn't sound like a bad route to go, might do that. Now that I'm thinking about it though, I might just make a scripting VI that removes all the local help files from all VIs in a folder I select.
Doing it like that, I only have to run the script once and I'm done, unless I upgrade the package or have to do a LV wipe-and-reinstall. As opposed to having to do any of the other options for possibly many applications.
Thank you for the help!
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.