Open VI Reference Error in the executable version only

[richjoh]

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?

[crossrulz]

---

@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.

[cassaniti]

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!!

[TeraTech]

---

@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)." ?

[crossrulz]

---

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.

[Alexander_Sobolev]

• 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.