Using a project within another project

[David-Baratheon]

If I completed a project, and then wanted to use that project as a sub element within a new project, what is the best practise for doing this?

Also, what happens if I have 5 projects, and I called the main VI in each project "main"? If I then wanted to bring all of those projects together into one project with a menu function that calls up the project you wish to use, won't you effectively have multiple VIs all called main? 

I am working trhough the exercise sheet that I was given after core 1 and 2, and one of the challenges is to create a VI that calls up each of the previous VIs based on a menu.

I am concerned that working across projects might mean files get missed etc, so wanted to know the best practise for this.

[Hooovahh]

Well I've never had a time where I wanted to put a project in a project.  A project usually contains all files and builds that I want for a given...well project.  You can have multiple builds in a project so I don't really see a need to have multiple projects.

As for name space.  Having "Main.vi" in two different projects is fine.  They are opened in their own instance (context) and so there won't be a name collision, assuming you open them from the project.  As soon as you try to make one project with two Main.vi files you will have problems.  This is a reason to try to give a more descriptive name.  Another thing people do is put files in libraries to organize them.  This causes the name space to be appended with the library name.  So you actually have "My Library name::Main.vi".

I guess I'd like more information on what you are trying to do, and why you need multiple projects.

[David-Baratheon]

Its a set of 6 exercises from NI.

The first exercise is to create a series of dice rolls and perform some statistical calculations on your dice rolls.

Second is to have a state changing boolean system, so each time a button is toggled, the system detects the change in state (as opposed to detecting the current state).

Third is to create a multuplication table.

Fourth is to create a system that can read from the file you have outputted in stage 3.

Fifth is to create a menu button that lets you choose which of the previous 4 exercises you would like to run.

As I have created a different project for each of the first 4 questions, the fifth one will involve me suing projects within a project or referencing one project in another project.

The reason I use "main" is because I think of it like a C program, with a main function that calls my sub routines (Sub-VIs)

In future I may develop a VI for something, for example monitoring power. At a later date, someone might want a system that detects power and other things also. So I might use the initial project as a Sub-VI in my new project, so that is how it could conceivably be useful in the "real world"

Problems I could forsee, are if I copy a VI into another VI in a different project, that new VI may still be calling on sub-VIs stored in the previous labview folder. If in future that labview folder was deleted, my new project could no longer find the sub-VIs it was calling upon. Same issue could apply for other types of files my code might be using to run such as .dll files etc.

[Hooovahh]

---

@David-Baratheon wrote:

So I might use the initial project as a Sub-VI in my new project, so that is how it could conceivably be useful in the "real world"

---

A project is just a collection of files, it contains no source, and is useless on it's own.  Think of it as Windows explorer.  It is just a way of viewing your files you have on your disk.  You can't use Windows explorer as a file, you use it to view other files.  Make one project that contains all the source you want for a given build and deployment.  Files can be in more than one project at a time.

[David-Baratheon]

But doesn't that get messy? What if I create a new folder for my new project, and upon importing a sub-VI into my code, my VI now relies on files external to the initial folder I made for my VI. What if I can no longer access that extern location where the sub-VI is found? I just thought it seemed like good practise to keep all files for a project in on folder and sub folders

[Hooovahh]

I clearly don't know enough about what you are trying to do, but there are a couple options to keep it from getting messy.  The goal is really to have the project and the source have a mostly common path. while also not duplicating code.  You may have a folder structure like this:

My Project.lvproj

Main.vi

--Utilities

--Controls

--UI

But one alternative (that I admittedly haven't tired) is you can have multiple projects together.

My Project.lvproj

My other Project.lvproj

--Utilities

--Controls

--UI

--Top Level VIs

----Project 1 Main.vi

----Project 2 Main.vi

But honestly now that I'm talking about this, the reason that this type of layout is uncommon, is because sharing code between projects in the real world shouldn't be something that happens often, at least without a formalized reuse process.

If I have common code between two project, I personally will split the projects and have two copies of some code.  This seems unnecessary but I don't want to update code for one project, and have it also make changes for another project.  For me most the time a project is for a particular customer, for a particular job.  So a new project is made for each new program for each new customer.  The majority of the common code they share is stored in the <user.lib> and is available on the palette.  This code has a formal release process and is versioned and tracked.  If code has some incompatibilty then we need to roll back or forward the reuse for a particular project, but efforts are made to avoid this.  The code that might be common between two programs that isn't formally tracked, is copied in an ad-hoc reuse type of situation.

[Bob_Schor]

Deciding on how you want to handle Projects is something of Trial and Error.  I've adopted the idea of a nested set of folders on disk that correspond to a single Project, with the Project File appearing in the top level, and sub-folders being things like Documentation, Sub-VIs, Types, RT Target (with its own set of sub-folders), etc.  I make the folders in the Project (which are "virtual folders", and do not necessarily correspond to physical folders on disk) correspond exactly to the physical folders that constitute the Project.  This allows me to easily manage the Project as a single entity in SVN, for example.

I've wrestled with the question of how to handle "common utilities" that I want to use in multiple Projects -- should I have a single copy somewhere (where?), should I have multiple copies in each Project that needs them, or what?  For now, I'm using multiple copies, but I'm not that happy with this method.  One Virtue is if I migrate a Project from, say, LabVIEW 2012 to LabVIEW 2014, all of the sub-VIs migrate together, but a version in another (un-migrated) Project isn't affected, unlike the case with a single source.

A better idea, it seems to me, that I've not yet implemented, is to make a Package of my utilities and use VIPM to install them as User Libraries in LabVIEW itself.  Sort of Having Your Cake and Eating It, Too.

Bob Schor

[David-Baratheon]

Bob, I am glad I am not the only one struggling with this question 😄

So when you start a new project that utilises some old code, do you have to drag each individual VI into the new project folder? It sounds like that requires a bit of "messing around" each time. A VI can have sub-VIs which can have sub VIs as you know so do you have to copy each individual sub-VI across to the new project folder and then incorporate them one by one into the new project?

I was hoping their was a way so simply drag and drop the highest level VI across and it would copy all of the sub-VIs across with it.

[Hooovahh]

---

@David-Baratheon wrote:

I was hoping their was a way so simply drag and drop the highest level VI across and it would copy all of the sub-VIs across with it.

---

It does do this.  Well first there are auto populate folders which can be useful but has it's draw backs.  There are snapshot folders too which might be more appropriate.  But if you just drag the top level VI over, all of it's dependencies will be loaded and put under dependencies.

[David-Baratheon]

Ah ok so if I copy a VI from one project into another whilst both projects are open (from the icon next to the connector pane) it will automatically copy the VI and sub-VI into dependcies and make a local copy within that project folder?