build executable; remove VI tree.vi ?

[nyc_(is_out_of_here)]

---

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)

---

Could you explain this?

I don't want to break what he has done.

I will be modifying the files to be able to text a new version of the product.

[JÞB]

---

@nyc_(is_out_of_here) wrote:

---

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)

---

Could you explain this?

I don't want to break what he has done.

I will be modifying the files to be able to text a new version of the product.

---

Sure:

Not Ideal:

The library has a broken public member!  so any project that encludes the lvlib is uncompilable with default settings!

Yup My new project has a library with a broken member!

But, if I restructure Agilent 33401.lvproj like this: (Ignoring Untitled9)

Agilient 33401.lvlib has no broken members and my new project that encludes the lvlib compiles nicely without having to gyrate the additional exclusions / unused memebers / changing the lvlib dance routine (since I didn't want to own the lvlib just enclude it in the project)

Now you'll ask why not just leave that re-use lvlib in my projects dependancies?  Why add it to my new project?   I pull the lvlib into the lvproj to avoid conflicts on high mix test systems running LV code modules called from TestStand.  I May have a few dozen Sequences that each call the driver but only one that called on a specifc function in that driver that had a bug.  Now I can easilly add the "Fixed" vi to my new lvproj and still have access to privately scoped driver vi's without changing the lvlib at all and needing to revalidate all 15 sequences (Plus the Unit Tests in the librarie's owning project show no change!)  For Instrument drivers that are certified this usually isn't a huge issue.  For some other 3rd party tools or "Homebrewed" reuse code it gets more problematic.  Of course, then we track the known bug - design a new UT for the fix and update the bad lvlib when I have "Burden Hours" to spend.

[nyc_(is_out_of_here)]

So, I am understanding this correctly, I need to modify the Agilent MXA Series.lvproj?

But do I physically move VI Tree.vi file or leave it in its current location in the Public folder?

[JÞB]

---

@nyc_(is_out_of_here) wrote:

So, I am understanding this correctly, I need to modify the Agilent MXA Series.lvproj?

But do I physically move VI Tree.vi file or leave it in its current location in the Public folder?

---

Thats the way I would fix it.

• Open the instrument driver Project
• From Project Explorer Drag (FQN)" Agilient MXA Series.lvlib:VI Tree.vi on Agilient MXA Series.lvproj/My Computer"to the same level as the example folder.  (This will modify the lvlib by removing a member and the project by moving a member and the Tree vi itself by deleting its membership)
• The new FQN is now "VI Tree.vi on Agilient MXA Series.lvproj/My Computer" and Bob's your uncle.
• (If Necessary:) open your "Target" project that uses the driver lvlib  "Tree vi" may not have left on its own because it never moved on disk and Project Explorer may have tried to "Forgive" you- If its still there right click it and "Remove from project"  

Note: Nothing moved on disk!  so we know that our LabVIEW Ninja skills are crazy mad and SCC clean-up is already done!

[crossrulz]

---

@nyc_(is_out_of_here) wrote:

So, I am understanding this correctly, I need to modify the Agilent MXA Series.lvproj?

But do I physically move VI Tree.vi file or leave it in its current location in the Public folder?

---

Since this was a shipped instrument driver, I would leave it alone.  Otherwise YOU will have to maintain it through SCC and somehow get it in the right place on all machines that are using your code.  More trouble than it is worth.  Just use that checkbox to remove the unused items in the build spec and be done with it.

If the writers of that driver were smart, they would follow Jeff's advice and not include the VI Tree.vi in the library file.

[JÞB]

Let me clarify.  The practice of including Tree.vi in an instrument driver library.  Is the current standard for plug n play project style drivers.  It has some justification for historical reasons because of developer habits ingrained by experience.  It has only one drawback.  And, NYC just found the edge case where it becomes a minor issue.

My personal work practice is to vet the driver before committing to SCC.  Moving tree outside the lvlib during vetting is habitual when I am dealing with mixed test systems.

[Hooovahh]

Oh I just thought of a neat solution, that involves editing the tree VI.  I saw a tree VI recently that was not a broken VI because someone put a disable diagram structure and put all the VIs in it.  Well what if we put down a conditional diable diagram structure, and in the case with all the VIs we put the Run_Time_Engine == False, then when an EXE is built that VI will try to be added but it will not be a broken VI because in the run time engine case there will be no VIs.

[crossrulz]

---

@Hooovahh wrote:

Oh I just thought of a neat solution, that involves editing the tree VI.  I saw a tree VI recently that was not a broken VI because someone put a disable diagram structure and put all the VIs in it.  Well what if we put down a conditional diable diagram structure, and in the case with all the VIs we put the Run_Time_Engine == False, then when an EXE is built that VI will try to be added but it will not be a broken VI because in the run time engine case there will be no VIs.

---

Why would you even need it to be conditional?  You can grab items out of a disabled case of a normal Diagram Disable Structure.

Regardless, this would be a nice compromise.

[Hooovahh]

---

@crossrulz wrote:

Why would you even need it to be conditional?  

---

Because I find it harder to find the function I'm looking for when they are greyed out as they would be in the disabled diagram structure.  But in the conditional they would be seen as normal, just not included when built into an application.

[JÞB]

Uhm, Brian,  That won't work.  Conditions for conditional disable cases are not evaluated until run time so the complier still sees broken code.