Built executable won't include dynamically called subVIs (LabVIEW 2014 SP1)

[wiebe@CARYA]

---

@tst wrote:

---

@fede_c wrote:

---

Once the Main.exe executable is built, I run it and, as I expected, the application runs flawlessly, even if I delete Pinger.vi.

I don't see how, as this seems to be a complete mishmash. My guess would be that the VI is actually contained inside the EXE (which would happen by default when you include it in the build) and is already loaded in the EXE, in which case opening a reference by path to another VI will load the original VI (I think. See point 3 below).

In general, there are a number of things which changes between LV 7.1 and LV 2014 which could affect your scenario, such as:

1. In LV 7, VIs inside the EXE were saved at a single level. In later versions, they are saved using their original hierarchy by default.
2. In LV 2014, VIs can have their source code separated and unless you account for that, loading VIs from EXE can be more complicated.
3. At some point (I think LV 8.0), opening a reference by path to VI A, where VI A was already loaded from a different path, changed either to return an error or to stop returning an error and just use the loaded VI, but I don't remember which way.

I would suggest that you explain what your actual use case is, as I agree with Wiebe that it's likely there are other solutions, such as static VI references or dynamic dispatching. Loading VIs directly from an EXE is not a scenario I think I ever actually needed, even with plugins.

---

Also, in 7.1, VIs (anything really) in a case with a constant was compiled. In >8 (IIRC), optimizations start removing dead code, and VIs in a case with a constant where removed, and not added to the exe.

In 7.1, putting VIs in a case with a constant was actually the way to force VIs in an executable.

I'd always use static VI references if possible. This almost always forces the VIs in the exe. One exception is if the static VI reference is in only used in a VI that's only called from a VI that's only in memory from a static VI reference.

But then again, I avoid dynamically calling VIs in the first place. Only if the objects aren't known at compile time (plugins), you really need dynamic VIs. There are situations where the cost of avoiding dynamic VIs is higher than using them, but the break-even point isn't where most people think it is.

[fede_c]

---

wiebe@CARYA  ha scritto:

---

@tst wrote:

---

@fede_c wrote:

---

Once the Main.exe executable is built, I run it and, as I expected, the application runs flawlessly, even if I delete Pinger.vi.

I don't see how, as this seems to be a complete mishmash. My guess would be that the VI is actually contained inside the EXE (which would happen by default when you include it in the build) and is already loaded in the EXE, in which case opening a reference by path to another VI will load the original VI (I think. See point 3 below).

In general, there are a number of things which changes between LV 7.1 and LV 2014 which could affect your scenario, such as:

1. In LV 7, VIs inside the EXE were saved at a single level. In later versions, they are saved using their original hierarchy by default.
2. In LV 2014, VIs can have their source code separated and unless you account for that, loading VIs from EXE can be more complicated.
3. At some point (I think LV 8.0), opening a reference by path to VI A, where VI A was already loaded from a different path, changed either to return an error or to stop returning an error and just use the loaded VI, but I don't remember which way.

I would suggest that you explain what your actual use case is, as I agree with Wiebe that it's likely there are other solutions, such as static VI references or dynamic dispatching. Loading VIs directly from an EXE is not a scenario I think I ever actually needed, even with plugins.

---

Also, in 7.1, VIs (anything really) in a case with a constant was compiled. In >8 (IIRC), optimizations start removing dead code, and VIs in a case with a constant where removed, and not added to the exe.

In 7.1, putting VIs in a case with a constant was actually the way to force VIs in an executable.

I'd always use static VI references if possible. This almost always forces the VIs in the exe. One exception is if the static VI reference is in only used in a VI that's only called from a VI that's only in memory from a static VI reference.

But then again, I avoid dynamically calling VIs in the first place. Only if the objects aren't known at compile time (plugins), you really need dynamic VIs. There are situations where the cost of avoiding dynamic VIs is higher than using them, but the break-even point isn't where most people think it is.

---

It's interesting what you said about LabVIEW code optimizations; that could explain the different behaviours between versions 7.1 and 2014.

My goal is indeed that the executable contains the VI and loads it in memory without opening a reference to a VI file on the filesystem. I really can't find the reason why this project doesn't do that, given that the other (dummy) project I built in LV 2014 seems to behave the way I want.

In the "almost same" project developed with LabVIEW 7.1 I didn't need to force subVI inclusion in the executable by putting them in an unreachable branch of code. In the build settings I just added them as Dynamic VIs and built the executable; it worked fine.

I agree with you to avoid dynamic calls to subVIs and using static VI references instead. In fact, I switched to the latter solution, fortunately with minimal code redesign. For me it's an acceptable solution to my problem, although the case remains (IMHO) unexplainable.

[wiebe@CARYA]

---

@fede_c wrote:

I agree with you to avoid dynamic calls to subVIs and using static VI references instead. In fact, I switched to the latter solution, fortunately with minimal code redesign. For me it's an acceptable solution to my problem, although the case remains (IMHO) unexplainable.

A call with a static reference is still a dynamic call.

Although a static reference makes your dynamic life a lot easier than a string or path reference, no dynamic calls is even easier.

[tst]

---

@fede_c wrote:

---

... although the case remains (IMHO) unexplainable.

---

Well, as I said, your original description doesn't match what you're saying (you say you want the VI to be inside the EXE, but then you point to another path). We have pointed out several things which could affect how this behaves, but ultimately, without looking at actual code where this happens, we are reduced to guessing games.