Having an executable create a folder at the same directory level as the executable's folder

[colorimeter]

I have several different lvproj's which need to all be able to access a folder called Measurement. For example one lvproj creates measurement files that are read by the next one.

When I run the the lvproj's in their expected order, a Measurement folder is created at the same directory level as the folder containing each lvproj, and they access it at this location. For example the top folder contains a subfolder for MyLvproj1, MyLvproj2, MyLvproj3, and a Measurement folder. However when I build the lvproj's then run the exe's, they each create a Measurement folder as a subfolder under the folder containing the exe. Then they can't find the Measurement folder that a prior exe put its measurements file in. 

How can I make the exe's create a Measurement folder at the right location? I know this can be done, because the exe's of a prior version of the code did this, but I can't figure out how.

[Mark_Yedinak]

Use the "Get System Directory" Vi to get the base for a common folder. I recommend using the ProgramData, Public Documents or User Documents folder as the base path for your files.

[altenbach]

Unfortunately, you are not telling us how you are doing all this, so we cannot really tell what you are doing wrong.

As has been implicitly guessed already, you might incorrectly use the "current VI path", which is treated differently depending on the environment (i.e. development system vs built executable, details) and thus required special handling. There are better ways!

I am also confused by your terminology. I assume that you are talking about the file location of the toplevel VI, because the location of the *.lvproj file is quite irrelevant for any of this (but they might be the same in your special case, who knows?). You also cannot "run a lvproj". A project is just a file that contains information about all the other files, settings, built specifications, and such.

If all three toplevel VIs always belong together, maybe they all should be in the same project and have a build specification that builds all.

Is there a reason you cannot combine all needed functionality onto one VI?

[rolfk]

There is a special Application property node returning that path but!!!!!

The location executables are installed is in any modern OS protected to be read only for normal users. You can NOT create folders or files in there from your program of even write to files. Only if the process is started elevated, can you do that. This elevation is even necessary if your account you are using has admin privileges (this may not apply to Windows Home, I don’t know as I never used that). 
So don’t try to do that it’s a pretty bad idea. Look for other locations such as the Users Document directory!

[colorimeter]

@altenbach, this is legacy code and I am a beginner, so I am hesitant to merge it all into one lvproj. But that is a good long term idea. I apologize for my unclear explanation. I will try to clean it.

[altenbach]

---

@rolfk wrote:

There is a special Application property node returning that path but!!!!!

---

I was wondering about that possibility too, but since installers were never mentioned, I though the more likely scenario would be that all exe locations are in the user folder. Who knows.? 😉

[LLindenbauer]

---

@colorimeter wrote:

... I am a beginner, so I am hesitant to merge it all into one lvproj.

I have experienced moving legacy code between moderately complex projects with reference conflicts to be almost certain to break Your code in ways that may as well be irrecoverable ...

I will try to clean it.

---

... Therefore I strongly recommend You thoroughly back up all Your code before doing so, in such a way that the LabVIEW IDE cannot reach it. Most SCC tools should work fine. Which is very much recommended anyway.

[billko]

---

@LLindenbauer wrote:

---

@colorimeter wrote:

... I am a beginner, so I am hesitant to merge it all into one lvproj.

I have experienced moving legacy code between moderately complex projects with reference conflicts to be almost certain to break Your code in ways that may as well be irrecoverable ...

I will try to clean it.

---

... Therefore I strongly recommend You thoroughly back up all Your code before doing so, in such a way that the LabVIEW IDE cannot reach it. Most SCC tools should work fine. Which is very much recommended anyway.

---

Yes!  SCC is a must.  Good advice.