extra folder added into the current vi's path function when compiled into executable

[TegtmeierD]

I found a new issue (to me) with the "Current vi's path" function today. When I compile the source code into an executable, I get a strange response from the function.

I expect to see "application.exe\application.vi".  What I am seeing is "application.exe\folder\application.vi". This is messing up my normal routines that automatically deal with the extra path removal step that is required when moving between executables and source code. I understand that I can use the "Application Directory" function and it does resolve this issue. However, as a test I created a separate program with only the "Current vi's path" function and it again worked normally (application.exe\application.vi). There seems to be something specific to this one application that I do not understand.

I have tried a force all recompile (ctrl-shift-run arrow) and this did not help. I created a new project with the same source and this did not help. I saved the source file as a different filename and created a new project for this new source file and it did not help. I was using the current vi's path function twice in the top level vi, so I changed this to only use it one time and it did not help.

I am running out of ideas and this is a large enough project that I really do not wish to start it over. The extra folder is part of the path to the source vi file. Any ideas on what would cause the extra folder information to be inserted into the path returned by the current vi's path function? 

I am using LV2012

[tyk007]

Virtual folders in the project?

[JÞB]

---

@tyk007 wrote:

Virtual folders in the project?

---

more likely "Auto populating" 

[James.M]

It would help for you to include the source code if you can.

Check your installer/executable settings to see if you're creating a subfolder with your distribution settings.

[Hooovahh]

You said you had a working solution using the the Application Directory, why would you need to start over?  If you want the folder that the current VI is in I usually use the OpenG function which is Current VI's Parent Directory.  This VI just takes the current VI path and keeps stripping out sections, until it arrives at a folder.

This or the Application Directory are better designs to go with because it doesn't rely on the internal structure of the EXE which you have little control over.

Oh and one other thing you can force yourself to do if you want.  In the application builder you can set the 8.x file layout which forces a flat file structure in the EXE.  Before 2009 all EXEs had no folders in them, when classes and libraries came around you could have VIs on disk with the same name.  This flat file structure then would have issues, so forcing the 8.x layout will add external dependencies to get around the naming issue.

http://zone.ni.com/reference/en-XX/help/371361L-01/lvdialog/app_settings_tab/

[TegtmeierD]

Hooovahh, you are correct that I do have a working solution by using the application directory function. At this point, I am trying to understand why this has occurred as I have never seen this behavior before when using the current vi's path function.

James, Where do I check the "distribution settings" to check for the sub-folder. I am not intentionally changing the default behavior of the installer. Additionall, when I created a second project, it did the same thing. Unless this is somehow a default behavior for the installer, I do not see how this is ocurring. If you can point me in the direction of how to check this, I will look for it.

Jeff, where do I check for the auto-populating that you are talking about?

tyk007, I have not intentionally added virtual folders to the project, how do I check for this?

Additionally, I made a copy of the source code and created a separate project to manage this copy. I have started selectively removing sections of the program and re-compiling to see if the issue goes away when using the current vi's path function. I already know that if I remove the majority of the code, the issue goes away. I am now taking smaller sections of code away to try to pinpoint what in the code is causing the issue. Callng the current vi's path function is one of the first steps in the program, so even if the program no longer accomplishes it's main goal, I can check to see if the function is working or not.

Thank you all for looking into this for me.

[tst · Accepted solution]

Generally, you shouldn't care about how exactly VIs are stored inside the EXE. If you do care, that means your code relies on it, which is a problem. The following is general and may be inaccurate, simply because I don't care enough to actually check how correct it is:

1. The EXE is basically a zipped folder containing the VIs and the LV runtime engine simply loads and runs them.
2. If you use the 8.x flag, you get a flat structure in the EXE. This isn't your case and I wouldn't recommend it anyway.
3. If the flag is false, LV basically takes all the VIs which need to go into the EXE (static dependencies of the included VIs and libraries) and places them into the EXE using the exact same folder structure that they have as code. This allows you to strip and build paths and have the code work in the same way.
4. Code which is in the LV folder (like vi.lib code) is placed in a top level folder called 1abv1ew, so it can be found.
5. If you need to get the folder path, use the app dir VI.
6. If you need to get a VI path, use a static reference to the VI and a property node to get its path property. This will work in both dev and EXE.
7. Virtual folders are irrelevant (they don't affect paths). Auto-populating folders are linked to disk, so they do reflect path information, but that's not really relevant. Jeff was simply pointing out that this can reflect the path and that he doesn't like them.
8. Most likely your issue (since you say something changes) is that you're sometimes including a VI which isn't in the same folder hierarchy of the top level VI, which then changes the top level folder in the EXE (I'm guessing a VI from another project?). This is easy enough to check by going to the files tab in the project and seeing if you have VIs from another folder.

Hopefully, this helps explains it, but like I said, you should generally not care about it. The only good reason I can think of for needing to know this is if the paths inside the EXE exceed the path length limit of the OS, and then you need to start dealing with that. Other than that just use the rule of thumb that VIs inside the EXE have the same structure as they did before and to get outside the EXE you should use the app dir VI.

[TegtmeierD]

Thank you tst, that is all the information I needed to understand the issue. You were correct that there were two sub-vi's referenced from a parallel directory and this is what was causing the issue. I had not tried the 8.x flag, but I suspect that this would have also resolved the issue. Because the 8x flag is non-preferred, I will move forward simply using the recommended solution in all new code development.

I had found that removing the referenced vi's from the overall program had resolved the issue, but until now I was not sure why.

Thanks again

[D@vidO]

Thank you!!!! 😃

Upgraded some old code from 8.6 to 2015 and all hell broke loose and spent half a day trying to figure this out.

Use "LV8.x file layout" solved it, but I will rewrite to use Application dir instead.

Problem does not occur in LV 2013 while the "use 8.x layout" is present.

Does anyone know from what LabVIEW version this "folder-feature" is actually present?

And perhaps a teminology to find info in the LV help?

Cheers!

/David

[crossrulz]

---

@David@Damill wrote:

Does anyone know from what LabVIEW version this "folder-feature" is actually present?

---

LabVIEW 2009 is when the executable hierarchy was released (hense why the flat hierarchy is called "8.X format").