build executable; remove VI tree.vi ?

[nyc_(is_out_of_here)]

I have taken over a new contract job.

The former LabVIEW person has left the company and is unavailable.

In the Word file he left behind, he writes

To build an executable or installer in the system test, you have to remove 1 file from the project. The file is called VI tree.vi from the Agilent MXA Series library. Remove the vi and build. When you save the project, it will complain. Dismiss the errors, and it will allow you to proceed.

The Agilent MXA VIs are in a lvlib

Isn't there an easier way of doing this?

[Hooovahh · Accepted solution]

The only reason I could see wanting to remove the Tree VI is because that VI is broken and can't run.  Usually this is because it has subVIs with requried inputs, and the tree VI is really just there to show you the functions, sometimes in the same layout as a palette view.

Now having a broken VI usually is a problem because it can't run, but in modern versions of the application builder under the Additional Exlclusions section you can have things like "Remove unused members of project libraries" this will remove VIs that aren't acually used from the build process.  If this isn't checked your broken VI will be added, and then the build will fail because a VI is broken.  Is this the problem the original developer had?

[crossrulz]

I'm with Brian here: use the Remove Unused Members Of Project Libraries in the build spec.  I then recommend NOT checking the Modify Project Library File option.

[Hooovahh]

---

@crossrulz wrote:

I then recommend NOT checking the Modify Project Library File option.

---

I always thought that was a dangerous setting to have on by default.  I mean lets say I use an API for talking to some hardware.  In my example I make an EXE that only uses the Init, read, and close, and not the write.  Since I didn't use that write function it won't include it in the EXE, but because I have the setting to modify the library does it then save that API with those file not in it?  I've always thought that's what that setting would do and thought that was crazy.

[crossrulz]

---

@Hooovahh wrote:

---

@crossrulz wrote:

I then recommend NOT checking the Modify Project Library File option.

---

I always thought that was a dangerous setting to have on by default.  I mean lets say I use an API for talking to some hardware.  In my example I make an EXE that only uses the Init, read, and close, and not the write.  Since I didn't use that write function it won't include it in the EXE, but because I have the setting to modify the library does it then save that API with those file not in it?  I've always thought that's what that setting would do and thought that was crazy.

---

Straight from the LabVIEW Help:

Modify project library file after removing unused members—If you select to remove unused members of the project library, enable this checkbox to direct LabVIEW to modify the library so that the library file does not refer to the removed members. If you do not modify the project library, the application may take longer to build.

I agree, that is a very dangerous setting.  But it is there to help the build process, apparently.

[nyc_(is_out_of_here)]

---

@Hooovahh wrote:

The only reason I could see wanting to remove the Tree VI is because that VI is broken and can't run.  Usually this is because it has subVIs with requried inputs, and the tree VI is really just there to show you the functions, sometimes in the same layout as a palette view.

Now having a broken VI usually is a problem because it can't run, but in modern versions of the application builder under the Additional Exlclusions section you can have things like "Remove unused members of project libraries" this will remove VIs that aren't acually used from the build process.  If this isn't checked your broken VI will be added, and then the build will fail because a VI is broken.  Is this the problem the original developer had?

---

Yes, that VI is broken.

I am not understanding why he'd want to include the Tree VI. Why not just leave it out of the LabVIEW project file.

[Hooovahh]

---

nyc wrote: 

I am not understanding why he'd want to include the Tree VI. Why not just leave it out of the LabVIEW project file.

---

Didn't know any better?

[crossrulz]

---

nyc wrote:

I am not understanding why he'd want to include the Tree VI. Why not just leave it out of the LabVIEW project file.

---

It sounds like that was a shipped driver for the MXA series instruments.  It is very common to include a VI Tree.vi in those.  The library should probably actually be in the instr.lib folder.

[nyc_(is_out_of_here)]

---

@crossrulz wrote:

---

nyc wrote:

I am not understanding why he'd want to include the Tree VI. Why not just leave it out of the LabVIEW project file.

---

It sounds like that was a shipped driver for the MXA series instruments.  It is very common to include a VI Tree.vi in those.  The library should probably actually be in the instr.lib folder.

---

The library for the MXA is in the instr.lib folder, but then it looks like he created a lvlib out of those VIs. 

EDIT: It looks like the lvlib came with the driver.

[JÞB]

This is actually one of the things I wish would be re-thought by the Instrument Driver Group.  Tree.vi should never directly call a Private Library member and should reside in the Driver Project but outside the library (Just like the examples).  Now when you enclude the lvlib in your project you don't enclude the broken vi as a dependancy and everybody is happy

EXCEPT:

The trouble is too darned many developers are so used to navagating a "Tree.vi" because they don't bother to push their .mnu files with their libraries thus shooting themselves in the foot.  And "Tree.vi" was the only thing that could save you back before project explorer existed.  So, the bad habits we as a community adopted because of limits in the IDE haunt us today.  

Better Practice:

Create the Functions palatte for your API to your library then, do not enclude "Tree.vi" inside the library your API calls into. (Tree.vi will be on the Fn Pallets that you should be Quick-dropping from anyhow)