Files not found in Dependencies

[stgislander]

I've been working on a LabVIEW project that was forwarded to me from another programmer.  I had to add additional control algorithms.

As I was reviewing the Project Explorer tree, I noticed that one .clt and one .vi file were not listed under Dependencies.  They are listed one level up under my cRIO platform.  I'm not sure how/why that happened.  

Is that a problem?

I'm not sure how to get them where they should belong.  I cannot drag-n-drop then into Dependencies, and if I right-click Dependencies there is no 'Add File' option.

[Bob_Schor]

Whenever I see a file in "Dependencies" that "belongs to me", that tells me that I forgot to include it in the Project.  I work hard to make "Dependencies" only have things that NI provides, or are from a Library (or equivalent) that is supposed to live outside the Project.

At the present time, a (fairly small, "beginning") Project of mine has user.lib, vi.lib, a number of VIs and .lvlib files related to Channel Wires, nilvaiu.dll (I have no idea what that is, but it starts with "ni", so it presumably "belongs"), PipeLogic.lvclass (more Channel Wire stuff), and to VIs related to Probes.  Most of these dependencies are in National Instruments\LabVIEW 2019\resource.

Bob Schor

[stgislander]

That's interesting.  So none of the VIs or controls you've created for your project appear under Dependencies.

As I was stumbling and bumbling around I discovered that if I drag-n-drop the vi file back up into the SubVi folder under My Computer and remove the ctl file from my project, and then click File>Save Project, LV automatically put those two files back under Dependencies where I was expecting them.

[billko]

It's hard for me to imagine a scenario where the VI or control that you make doesn't appear in your project proper.  Assuming the project is open, anything you make should go somewhere in the project unless you explicitly added it as a dependency.

[Bob_Schor]

---

@stgislander wrote:

That's interesting.  So none of the VIs or controls you've created for your project appear under Dependencies.

Yes, that's usually the case.  I generally have the Project open when I do my development, so any VIs I create are "seen" by the Project, and when I exit the Project, it prompts me to save the opened (if unsaved) VIs and "remembers" where they are located.  I do make it a point to save them in an appropriate Folder inside the Project Folder (I usually have a sub-Folder called Sub-VIs, one called "Types", and, of course, if I'm doing LabVIEW-RT, I have a Host and a Target folder (inside of which are separate Sub-VIs and Types folders).

I do occasionally find "orphan" files under Dependencies.  When this happens, I find them on disk, move them into the Project Folder, then "add" them to the Folder in Project View, which removes them from Dependencies.

As I was stumbling and bumbling around I discovered that if I drag-n-drop the vi file back up into the SubVi folder under My Computer and remove the ctl file from my project, and then click File>Save Project, LV automatically put those two files back under Dependencies where I was expecting them.

Yes, you removed them from the Project and made them "Dependencies".  So if you use the same VI in some other Project and change it, the Project in which has it as a "Dependency" will also see the change, and may mysteriously "break".  You don't want code/VIs on which you are "dependent" to change without your consciously changing them with your Project in mind.

---

Bob Schor

[JÞB]

---

@billko wrote:

It's hard for me to imagine a scenario where the VI or control that you make doesn't appear in your project proper.  Assuming the project is open, anything you make should go somewhere in the project unless you explicitly added it as a dependency.

---

Let me get your imagination working. 

If you look in some of the Shipping Project Templates you will find a library of Command Queue handling VIs complete with an API.  Maybe you prefer a slightly different CMD Queue style (let's not digress into debates about Queue data as <String, Var>, <Enum,<Class>>, etc...)

Anyway you like those command queues, you can adapt that Lvlib as a general Command Queue resource library and place it in MyCompanyReuse code.  MyCompany Developers can create Project Templates that use that reuse library and gain tons of benefits by reducing project development time and duplicating code review of that library module.  Plus, since the projects are on a common template the integration and maintenance team members see similar code standards for every solution.  TheseLibraries used across SimilarProjects belong in dependencies.  Whereas, ThisLibrary used only for ThisProject belongs in the Project. 

If you think that those benefits will never add up, think again and, do your thinking on a train!!!

Yup, that's how we met the time set by the US Congress for deployment of Positive Train Control manufacturing test systems.  (Well, those brand spanking new NI VSTs were a huge time-saver too)

[stgislander]

That sounds very useful.  We've created a handful of subVIs that can be used across projects.  Having them in a library would simplify things.  Especially when creating new projects from existing ones. 

[billko]

---

@JÞB wrote:

---

@billko wrote:

It's hard for me to imagine a scenario where the VI or control that you make doesn't appear in your project proper.  Assuming the project is open, anything you make should go somewhere in the project unless you explicitly added it as a dependency.

---

Let me get your imagination working. 

If you look in some of the Shipping Project Templates you will find a library of Command Queue handling VIs complete with an API.  Maybe you prefer a slightly different CMD Queue style (let's not digress into debates about Queue data as <String, Var>, <Enum,<Class>>, etc...)

Anyway you like those command queues, you can adapt that Lvlib as a general Command Queue resource library and place it in MyCompanyReuse code.  MyCompany Developers can create Project Templates that use that reuse library and gain tons of benefits by reducing project development time and duplicating code review of that library module.  Plus, since the projects are on a common template the integration and maintenance team members see similar code standards for every solution.  TheseLibraries used across SimilarProjects belong in dependencies.  Whereas, ThisLibrary used only for ThisProject belongs in the Project. 

If you think that those benefits will never add up, think again and, do your thinking on a train!!!

Yup, that's how we met the time set by the US Congress for deployment of Positive Train Control manufacturing test systems.  (Well, those brand spanking new NI VSTs were a huge time-saver too)

---

I was really referring to making VIs within a project.  We have similar "general use" libraries that are used in the same way.  Specifically, I was referring to the generation of VIs, themselves.  No matter how I end up creating a new VI, for instance, as long as the project is open, it goes somewhere in the project, not in the dependency folder.

[tst]

---

@stgislander wrote:

As I was stumbling and bumbling around I discovered that if I drag-n-drop the vi file back up into the SubVi folder under My Computer and remove the ctl file from my project, and then click File>Save Project, LV automatically put those two files back under Dependencies where I was expecting them.

---

The topic veered off a bit, so just to make it clear: the dependencies section shows VIs which are called by the VIs in the project. It's not something you manage. It's a useful tool, but has no direct semantic meaning on the execution/structure of the code. In your case, I'm guessing that moving the VI to a different target removed it from the cRIO target, but it's been a while since I worked with multiple targets, so that's just a guess.

As for the direction the thread went, it's really a matter of preference. I personally tend to go the opposite way of having the project include just things which are required (top level VI, build support items, auto populating folder if I happen to have them) or which for some reason I want to have in the project and the others are handled automatically.

Both options probably have their pros and cons and in the end, it shouldn't really matter which one you choose. I would suggest that the Files tab in the project is a more useful tool for seeing dependency issues (or at least cross-linking issues) than the dependencies section.

[JÞB]

---

@tst wrote:

---

@stgislander wrote:

As I was stumbling and bumbling around I discovered that if I drag-n-drop the vi file back up into the SubVi folder under My Computer and remove the ctl file from my project, and then click File>Save Project, LV automatically put those two files back under Dependencies where I was expecting them.

---

The topic veered off a bit, so.....

 I would suggest that the Files tab in the project is a more useful tool for seeing dependency issues (or at least cross-linking issues) than the dependencies section.

---

I would differ.... turn on the Show Paths setting in the Project View and those nasty.linking issues become obvious!  The Right side of the Explorer Window is super easy to use!  Use the Files View ONLY to move items on disc (NOT Windows Explorer) and turn off Auto-Pop folders! Virtual.folders work with fewer "issues" while auto-pop folders really are only useful when converting unmanaged code and llbs to lvprojs and lvlibs.