LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

nested lvlib madness

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.

 

0 Kudos
Message 11 of 13
(69 Views)

@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".

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 12 of 13
(42 Views)

@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?

0 Kudos
Message 13 of 13
(28 Views)