nested lvlib madness

[AlexElb]

Hey I'll wake up this old question,

tested with LV 16 and 18:

1. open project counter.lvproj
2. add project.lvlib to the project
3. create test.vi inside project, but not inside one of the two libs
4. change counter.vi scope to public and drop it in test.vi
5. save everything
6. test.vi is runnable
7. delete neatAPi.lvlib from the project: it goes under dependencies, test.vi is still runnable
8. add neatAPI.lvlib to project.lvlib with Drag & Drop (!) from dependencies to the lib and save: test.vi is still runnable
9. repeat step 7: delete neatAPi.lvlib from the project: it goes under dependencies, test.vi is still runnable
10. add neatAPI.lvlib to project.lvlib with Right Click -> Add File (!): test.vi is not runnable!

So there are two methods to add a lib to another lib (right click add and drag & drop) which lead to different results. Is this a bug or a feature? Can someone explain please?

It does only make a difference if test.vi is NOT part of project.lvlib - otherwise LV updates the reference correctly.

[billko]

---

@AlexElb wrote:

Hey I'll wake up this old question,

tested with LV 16 and 18:

1. open project counter.lvproj
2. add project.lvlib to the project
3. create test.vi inside project, but not inside one of the two libs
4. change counter.vi scope to public and drop it in test.vi
5. save everything
6. test.vi is runnable
7. delete neatAPi.lvlib from the project: it goes under dependencies, test.vi is still runnable
8. add neatAPI.lvlib to project.lvlib with Drag & Drop (!) from dependencies to the lib and save: test.vi is still runnable
9. repeat step 7: delete neatAPi.lvlib from the project: it goes under dependencies, test.vi is still runnable
10. add neatAPI.lvlib to project.lvlib with Right Click -> Add File (!): test.vi is not runnable!

So there are two methods to add a lib to another lib (right click add and drag & drop) which lead to different results. Is this a bug or a feature? Can someone explain please?

It does only make a difference if test.vi is NOT part of project.lvlib - otherwise LV updates the reference correctly.

---

I can, indeed explain this as "expected behavior".

When you drag it from dependencies to the project, you are actually removing it from dependencies at the same time, whereas when you add it from the menu, it only does the add part, leading to a conflict.  They are two distinctly different operations.  One is "move" one is "add".

[AlexElb]

---

@billko wrote:

---

When you drag it from dependencies to the project, you are actually removing it from dependencies at the same time, whereas when you add it from the menu, it only does the add part, leading to a conflict.  They are two distinctly different operations.  One is "move" one is "add".

---

Hey Bill,

thank you for your response. Could you explain the expected behavior please in more detail? Is there some excellent link where this is described? I find myself often in conflicts when copying and moving files around, so a guide with do's and don'ts would be very usefull...

a VI A uses another VI B which is stored under a path. The project explorer knows, where B is located, even if B is not added to the project, so B is shown under dependencies. Now the user adds B manually to the project and B is no longer under the dependencies. What is the advantages of A now not knowing, that B was added?

Why does it make a difference, if A is part of the lib to which B will be added?