LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI Reference Error in the executable version only

Solved!
Go to solution

Yes thats absolutely correct, relative path for the current VI path and relative path on llb. This works with out moving llb files and keeping no change on the build the I take it?

0 Kudos
Message 21 of 26
(3,165 Views)

@richjoh wrote:

Yes thats absolutely correct, relative path for the current VI path and relative path on llb. This works with out moving llb files and keeping no change on the build the I take it?


No changes at all.  If you move the llb, then your relative path location changes.  But the current LabVIEW executables keep the directory structure inside of the EXE.  So if you keep a relative path to your current VI correct, then it will just still work in the exectable.

 

Note that you will still have to tell the executable build to always include the dynamically called VIs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 22 of 26
(3,159 Views)

Wow first of all thanks! This solved my problem and allowed me to learn something new!

No need for case at all, just this interesting structure with "current VI's path" and ..\LLBname.llb (if I understand right, the effect of ..\ is to use directly the folder, another trick I've just learned).

Thanks again!!

0 Kudos
Message 23 of 26
(3,149 Views)

@crossrulz wrote:

Why are you not using the Current VI's Path function and build from there?  You should really only use the Application Directory for external files (like configuration files).

 

This code worked for me in both the development environment and the executable.


Crosrulz: can you explain why "You should really only use the Application Directory for external files (like configuration files)." ?

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 24 of 26
(2,578 Views)

TeraTech wrote:

Crosrulz: can you explain why "You should really only use the Application Directory for external files (like configuration files)." ?


Absolute paths of VIs can change inside of your EXE.  This usually happens when you use a VI that is in a separate directory tree or the like.  So within an executable, use the relative path of the VIs to find your dynamic VI.  But anything outside of the executable (config files, data files, etc.) will have different relative paths to the VI, but you can maintain the relative path to the project file or executable.  Therefore use Application Directory for anything outside of the executable.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 25 of 26
(2,563 Views)
  • why "You should really only use the Application Directory for external files (like configuration files)." ?

I agree that there should be no fixed paths and Application Directory is the best for libraries, but configuration files that are modified during execution are better be stored in Public (or current User) Documents.

Program Files (and application directory) usually have access restrictions for all folders by default and you might not be able to write to the file from program with User rights.

0 Kudos
Message 26 of 26
(2,546 Views)