Building a LabView executable with supporting files

[prettypwnie]

Use "Application Directory" instead of "Current VI's Path"

Also, you should not use string constants with \ in them as inputs to Build Path. Change them to path constants.

[mcduff]

The application directory is the right call, however I would like to recommended the following modification, that way you can switch from development environment to application environment without worries.

Both Cases Shown

mcduff

[crossrulz]

McDuff, part of the point of the Application Directory is that you do not need to mess with the App.kind.  As already stated, just make sure your support files have the same relative path to the project file as your executable.

[mcduff]

Got it, thanks.

Sometimes though I do not always use the same relative path, not sure why, I guess that is sloppiness on my part. (The support directory in the EXE always default to the ...\myapp\data, did not know that could be changed.)

Cheers,

mcduff

[nonone01]

Thanks to everyone that responded. Your feedback helped and now I have a functional executable.

regards

[TeraTech]

---

@crossrulz wrote:

McDuff, part of the point of the Application Directory is that you do not need to mess with the App.kind.  As already stated, just make sure your support files have the same relative path to the project file as your executable.

---

@crossrulz, can you explain (illustrate?) exactly how you would use Application Directory for relative file path discovery that works at BOTH development time and run time?
It is my understanding that at run time (from an executable) the path to a sub folder must not only include the application directory of the exe but also include the exe filename itself, right?  For example:

Say you have a development folder structure:
C:\lvproj-folder\test sequences

and an installation folder structure (where you exe is installed) of:
C:\exe-install-folder\test sequences

Using Application Directory vi at development time gives you: c:\lvproj-folder
Using Application Directory vi at development time gives you: C:\exe-install-folder
However (and this is my point of question) to actually access the sub folder at run time (inside the exe) would need to be:

C:\exe-install-folder\application.exe\subfolder
NOT following: C:\exe-install-folder\subfolder

So that means that at run time I would need to add the exe name to the output of the Application Directory vi, which means I need to have use the App.Kind property to drive a Case statement right?

[Gregory]

However (and this is my point of question) to actually access the sub folder at run time (inside the exe) would need to be:

C:\exe-install-folder\application.exe\subfolder
NOT following: C:\exe-install-folder\subfolder

No, the discussion is about a subfolder next to your executable, not inside of it. The default one is called "data" I believe, but I usually have a "config" folder as well.

[natasftw]

---

@TeraTech wrote:

---

However (and this is my point of question) to actually access the sub folder at run time (inside the exe) would need to be:

So that means that at run time I would need to add the exe name to the output of the Application Directory vi, which means I need to have use the App.Kind property to drive a Case statement right?

---

If it's inside the EXE, it's compiled and can't change.  If you're creating files, I'm not sure how.

Your solution is to use a logical file structure for saving and running your app.  That way, the relative path from the project and the EXE is the same.  At that point, no.  You will not need a case structure to drive anything.

A key learning point here, if it's able to change, it's NOT in the EXE.  It's referenced by the EXE

[TeraTech]

Sorry, as the previous reply indicated I now realize this discussion is about support files not referencing vis in the exe at run time.