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

[billko]

---

@tst wrote:

---

@billko wrote:

---

---

IMO you should unlearn this habit right away! 

---

I disagree. While there are various good reasons to start with a project, the process described by BK75 should generally work and is not wrong.

I agree that projects and SCC should be used, but I think this entire discussion is a red herring and the current important thing is why is the build not working. Uli's questions seem on point.

My initial guess would be that the VIs are called dynamically by path and are simply not included in the build, but it could also be a matter of front panels being stripped, etc.

Without code, it's pretty much impossible for us to tell.

Things which can help:

1. Posting the code or at least more details on how it works
2. Adding error handling
3. Stripping it down to a simple example with one subVI and seeing what happens there.

---

I'm thinking that if the project were built in the normal way, this wouldn't happen.  Maybe it's not wrong, but I think that doing it in an unexpected way like this opens the door to all kinds of unexpected issues.  I guess what I'm trying to say is that things that are usually obvious - like adding dynamically loaded VIs to be always included - will often get overlooked because you're not thinking about the project structure until you throw everything altogether at once.  There's a big reason why you start with a project first, and that is to get your mind thinking about all the relationships first and foremost, and not as an afterthought.  So yes, I am sticking to my guns on this.  Not because something happened with the build, but the workflow used would be very prone to issues like this.

[tst]

To be clear, I agree: start with a project. Definitely a good habit to adopt. I just think it's not as critical (and I don't think something like including dynamically called VIs is necessarily "obvious" to everyone, regardless of whether or not you have a project).

[billko]

---

@tst wrote:

To be clear, I agree: start with a project. Definitely a good habit to adopt. I just think it's not as critical (and I don't think something like including dynamically called VIs is necessarily "obvious" to everyone, regardless of whether or not you have a project).

---

Thanks for the clarification.  I agree that this isn't the root cause; I just ascribe a little more significance to its role in contributing to the issue than you do, that's all.  For clarity from my side, I am just suggesting that adopting a more conventional workflow would, in the future, help to avoid these kinds of issues.  This is just my opinion, though.  It's what works for me because it keeps things like that in the forefront of my mind.  it may not do that for other people, though.

[BrianK75]

I spent the morning writing a simple favorite football player example Main.vi with a variety of different sub.vis.  It is an ugly, basic state machine with no dynamic events.  I did put in an image into the last sub.vi as some of our programs use small images. It is cut/pasted into the front panel. It is not selected as a background and stretched throughout the entire front panel canvas. I ran it with and without it, still had the same result. 

I am attaching all of the vis, the referenced .txt files, all files that lvproj created, along with the build exe files in a .zip file. 

If the Main.Vi is ran alone or even within the project, everything works .  As soon as it is built into an .exe, It hangs immediately.  I previewed the file before being built, there were no errors.  I have tried changing all sorts of VI properties, rebuild, and still no luck. 

I tried researching NI all last night and went down the rabbit hole of chasing Runtime issues.  I tried building the exe on two different work computers along with my personal computer. Still the same result. 

My current work laptop uses:

LabVIEW Runtime 2019 SP1 f4 (64 Bit)
Windows 10

[RTSLVU]

The EXE runs fine for me...

Also here's a pro tip on how to run a case only once at startup...

[BrianK75]

@RTSLVU

Fair enough....Now run just the Main vi and see how it is supposed to run. 

What you are looking at is the Main VI hung up.  The Player list is not populating, there are no pop ups.  

[dkfire · Accepted solution]

The problem is that the path to your txt files are not correct when you but an exe. 

Try to add some indicators to the path for the files, and see what they say. 

And due to the files can not be loaded, there is and error on the error cluster. The Invoke Node for FP.Open will not run when an error is on the error cluster into the node. That is why you don't see the pop up vi's. Make sure that you handle errors correctly, and that any error do not block your program to not be able to end.

[BrianK75]

Wow dkfire! I replaced the "Curent VI's Path" with an actual drive location and rebuilt it....it worked!  Thank you!

I have no idea where the client will store the exe or the files to be read on their server.  

Therefore, I figured that by using the Current VI's Path reference and telling them to place the files into the same location, it would work.  I have spent a good week+ fighting with Application Builder and come to find out, using the Current Vi's Path does not mean what I thought or it has a flaw.....

And, yes, I did place the .txt files in both the .exe location and the location all the VIs. 

I ended up overwriting my Main.vi and starting completely over last week because I was trying anything and everything to get the exe to work.  I made a dumb mistake at 2am. 

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.  

It does appear that I can write VIs, create a project, pull in the Main.VI and its dependencies and create an exe.  I generally know the hierarchy of my structure since I am the only one programming on most of my projects. 

I will look at trying to create projects in the future to begin my VIs.  I will also look into SCC.  I have never needed it before but after this adventure.......I am in. 

I agree that having plans of the house before building is wise. 

Thank you!

[BrianK75]

Thank you RTSLVU.

I generally try to use your technique.  The project i posted was not great by any means but a sample vi of what I was experiencing. 

[RTSLVU]

Here's what I do when I want to include other files in the build.

I place the files I want to include in a directory under my project

In my build specification Source Files I set that directory to "Always included"

In the Destination I set the Support Directory to be that directory under the main exe

After I build the program my Headers Directory is right there where is should be

This is how I code the directory in my program.