LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Builder over wrote my Main.vi with an example vi?

Solved!
Go to solution

@BrianK75 wrote:

 

So, Current VI's Path reference will work perfectly in a vi with developers license. It will work perfectly in a .lvproj as long as you run it through the project.  Build and executable and you get sad trombones!   Lesson learned.  


I think the correct lesson in this case should not be about the specific behavior of paths (which is useful knowledge), but rather about the process of analyzing and debugging. If you run into an issue, you need to understand where the problem is, so you can solve it.

 

In this case, for example, error handling or logging (even a simple call to the shipping simple error handler VI) would have helped. Disabling sections of the code until the problem stops happening can also be useful, as well as displaying or logging values, etc. There are many ways to go and the important thing is just to do it.

 

All that is beside the discussion about good code, SCC, etc.

 

 

Oh, and as a side point, I haven't looked at the code, but the posted image does actually show one of the cases where working with a project would make an actual difference: the image shows the application directory VI, which behaves differently with no project, in a project or as an EXE (read the help for it). You probably wouldn't notice it in this case, as I'm guessing your project file and top level VI are in the same folder. This is certainly one reason to always work in a project, so you at least get consistent behavior in LV.


___________________
Try to take over the world!
Message 31 of 33
(279 Views)

The Application Directory VI was my input, that was not in the original vi from OP. 

But knowing how path works in exe vs vi's in the IDE, that was a quick fix to get the program on the right path. 

 



@tst wrote:

@BrianK75 wrote:

 

So, Current VI's Path reference will work perfectly in a vi with developers license. It will work perfectly in a .lvproj as long as you run it through the project.  Build and executable and you get sad trombones!   Lesson learned.  


 


Current VI's Path still works in an exe, you just need to know how an exe is build in LabVIEW and were vi's are placed vs use a vi in the IDE. 

When you build a vi to an exe the path of the vi will change, as it will get placed inside the exe. you will need to take care of that when developing an application in LabVIEW. 
There are multiple ways to handle that, so that when the code run as an exe the path to external files, like your txt files, are correct, but still dynamic to where the exe is placed on disk at the user end PC.

0 Kudos
Message 32 of 33
(266 Views)

Using the Application Directory vi fixed the issue.  

Using the Current VI's Path vi caused my original problem (exe would run but nothing would populate from the .txt references).

 

The Main with subs ran fine in development stage.

It also worked perfect when I developed a lvproj.

Upon building an exe, it lost connection to the references and hung up as dkfire stated. 

 

I compared the two path VI functions here:

 

BrianK75_0-1660147978589.png

Thank you very much.  This has been driving me crazy for a week now. This was the first time I tried to pull reference data from within the exe file. I generally put them in specific locations on a data acquisition system. The client wanted to them to be placed within the exe file so it could be installed onto different computers and different drive locations.  

 

I have built stand alone applications many times.  I have run into small issues with Applications Builder when involving MS Excel & Word within my vi.  I thought this was a properties issue I was dealing with since everything seemed to run perfectly in Dev. 

I was working on a few different computers in the development of this and started looking towards a version differences or runtime issues.  

0 Kudos
Message 33 of 33
(245 Views)