jmltinc Posted April 6, 2018 Report Share Posted April 6, 2018 Hi Folks, I have some popup VIs that can be called by the main VI's menu as well as from the popups themselves. These VIs are not dropped inside any VI, but are called dynamically using their path - either absolute or relative to the caller. My problem is, I do not know where the VIs might be placed at the time of the Build. Without going too deeply into the dirty laundry and politics of our company, the project was divided into 2 parts. One part is concerned with retrieving and writing data to a database (my part). This requires user interaction. My contribution is integrated into a legacy application "owned" by another person. That person controls the main VI as well as the Build and distribution. Unfortunately, he operates autonomously and without communication. Bottom line is I have no idea where he will place the VIs for the build and he may change the location at any future build. I cannot use the Get VI Dependency method because the popups are called dynamically and therefore do not exist on any block diagram. Is there any way to retrieve these paths within an executable at runtime? Yes, I know the answer is to work as a team, but that is not going to happen... Thanks, John Quote Link to comment
Chris_Collier Posted April 6, 2018 Report Share Posted April 6, 2018 One thing you could do is have a configuration file with specific titles for each filename. When you pass your build off to your co-worker, they can fill in the absolute file name (or you could make a flag to allow for relative to the project, if you want to) and work with it having those VIs wherever they want, and you shouldn't need to change your code no matter how often they move the VIs. Quote Link to comment
smithd Posted April 7, 2018 Report Share Posted April 7, 2018 (edited) They can be included statically even if you run them dynamically as popups. The normal route I go is to have a static VI reference then a property node to get the name out of that reference, which I then pass to open in order to get a dynamically launchable reference. By using the static VI reference you force labview to build the child into the caller and then you don't have to worry about where the build puts the VI Edited April 7, 2018 by smithd Quote Link to comment
drjdpowell Posted April 7, 2018 Report Share Posted April 7, 2018 One trick I've done in the past is to include a static reference to an empty subVI that I know will install in the same subdirectory as my plugins, and get the path to that subdirectory from the VI reference. Then I do a recursive directory search from that base directory for my plugins. 1 Quote Link to comment
jmltinc Posted April 7, 2018 Author Report Share Posted April 7, 2018 Thanks for the replies... A INI or text file won't work because my partner won't cooperate I haven't tried a static reference and using its reference. It is an interesting concept. I have tried putting the VI's in the FALSE case of a Case Structure residing outside of the Consumer Loop of the main VI. The conditional terminal is wired to a comparison function that will always call TRUE. Inside the TRUE terminal, I put the Get VI Dependency method which indeed returns the paths which I store in a cluster. Unfortunately, the popups in the FALSE case, even though not directly called, run in memory. When they are called dynamically, they open, but are hung and the main VI must be closed. I will try the Static trick and see what happens. Thanks, -John Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.