LV 2021 vs. newer, VI management in memory

[wiebe@CARYA]

---

@MaSta wrote:

What's also not clear: can LabVIEW manage dependencies itself completely, partially or not at all? If it does, no matter how, do I just have to the have the project file open? 

---

LabVIEW often can (and does) manage dependencies completely.

It can obviously not always do this. If a location changes to an unknown location, it does need help, and if a connector pane changes, you sometimes have to explicitly relink, etc.

If the caller is in memory, the changes happen straight away. If the caller is not in memory, it happens when it's loaded. Opening the project might not be enough. Opening the project only loads classes (maybe libraries, I never use them) and it's members. But a main VI that's not in a class won't be loaded, and dependencies won't be managed as you change them. 

[GerdW]

Hi MaSta,

---

@MaSta wrote:
I still don't see how and, most of all, why I would need to manage dependencies and not LabVIEW.

---

You don't need to manage dependencies.

LabVIEW will do that for you - once you use project files!

[MaSta]

Update:

I started using the project as click source to open sub VIs. It has an impact on how often the above mentioned pop-up comes. One big advantage is that called sub VIs are not listed in the project or only after the main VIs run and has called them.

It's not the "yellow of the egg" as we Germans use to say, but it helps.

Thanks again for all ideas and suggestions.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

One big advantage is that called sub VIs are not listed in the project or only after the main VIs run and has called them.

---

When the subVI belongs to that project then it should be included in the project file under "My computer" (or any other target you use)…

IMHO it would be a disadvantage to not have the subVIs visible in the project!

[Yamaeda]

---

@GerdW wrote:

Hi MaSta,

---

@MaSta wrote:

One big advantage is that called sub VIs are not listed in the project or only after the main VIs run and has called them.

---

When the subVI belongs to that project then it should be included in the project file under "My computer" (or any other target you use)…

IMHO it would be a disadvantage to not have the subVIs visible in the project!

---

They _are_ visible under Dependencies. 🙂 Sometimes it's nice to keep the main portion minimalistic.

[billko]

---

@Yamaeda wrote:

---

@GerdW wrote:

Hi MaSta,

---

@MaSta wrote:

One big advantage is that called sub VIs are not listed in the project or only after the main VIs run and has called them.

---

When the subVI belongs to that project then it should be included in the project file under "My computer" (or any other target you use)…

IMHO it would be a disadvantage to not have the subVIs visible in the project!

---

They _are_ visible under Dependencies. 🙂 Sometimes it's nice to keep the main portion minimalistic.

---

Optimally, subVIs not belonging to another distribution should belong under "My Computer", and it's not just for convenience, either.  There could be subtle build issues if they aren't.

[MaSta]

@GerdW: I actually meant to write "disadvantage", not advantage.

@all: I also started to think so. While the project was open, I crated a new sub VI and it was automatically added. I think it wouldn't disturb to add all sub VIs, though I have a lot meanwhile.

[GerdW]

Hi MaSta,

---

@MaSta wrote:

I think it wouldn't disturb to add all sub VIs, though I have a lot meanwhile.

---

You can also add complete folders automatically.

I hope you organized your subVIs in folders (atleast)!?

[wiebe@CARYA]

---

@MaSta wrote:

@all: I also started to think so. While the project was open, I crated a new sub VI and it was automatically added. I think it wouldn't disturb to add all sub VIs, though I have a lot meanwhile.

---

As long as the subVIs are organized (in vilibs or classes and\or (virtual) folders) that seems like a really good idea.

What's a lot? Up to a few k is no problem. I rigorously try to keep all my subVIs in my project esp. for projects with a few k subVIs.