The VI Hierarchy Window Should Only Show the Actual VI's in Use

[InternationAL]

I did a search for "VI Hierarchy" and didn't turn up this idea.  I sure hope it isn't a repeat. 

If you have a polymorphic VI in your VI hierarchy, when you view the hierarchy, it seems like every single polymorphic instance of that VI shows up, as well.  This doesn't help me at all, and I don't know why it works this way.  I should only see the specific VI's I am using.

After dropping just one function (DAQmx Read [Analog DBL 1Chan 1Samp])

Now check out my VI hierarchy!

It's gone berserk!  It is showing me every single flavor of DAQmx Read!  Try this for your own amusement.

Why don't I see only one DAQmx Read function in this hierarchy?  Or maybe someone can shed some light on why it SHOULD work this way.  I definitely think it SHOULDN'T.  The block diagram I posted above should not have a hierarchy like this!

Message Edited by Support on 07-30-2009 09:27 AM

[Jim_Kring]

I couldn't agree more.

[PJM_Labview]

Same here, you got my kudo.

[AristosQueue (NI)]

Hm... I was just going to ignore this idea, but it has enough Kudos and two "I agree" comments, so let's talk this through...

1. I hope everyone agrees with these two principles:
   • any VI in memory should be shown in the VI hierarchy and
   • if a VI is needed in memory because of another VI, it should be shown under that caller VI in the hierarchy window
   If anyone doesn't like this, we need to have a deeper conversation about what the purpose of the VI Hierarchy Window actually is.
2. There are 4 VIs we need to talk about in this conversation:
   1. The caller VI
   2. The poly VI (dropped on the diagram of caller VI)
   3. The called VI (the instance of the polyVI actually picked for invocation)
   4. The uncalled VI (the other instance of the polyVI that is not chosen)
3. The polyVI shows in the VI Hierarchy window. What do you expect a polyVI to show in its window? Shouldn't it show all the instance VIs that can be chosen? Those possible instances are its dependencies. In keeping with the assumptions I stated at the beginning, it is right and proper that all the instances -- both called VI and uncalled VI -- be shown under the polyVI.
4. The caller VI is shown in the VI Hierarchy window. If I pop up on that VI and select "Highlight Connections", I see lines going to the polyVI itself and to called VI. So the exact instance called by the VI is knowable.

In short, I think this idea would conflict with the goals of the VI Hierarchy Window and the information that the idea claims is unknowable (which instance is actually called) is actually represented. I think that the declaration "a VI that calls this particular DAQ VI should not have a diagram like this" is a complaint about the DAQ API, not about the VI Hierarchy window. Solution: Ask DAQ to have less polymorphism... of course, that might raise other problems.

[mzaleski]

Aristos,

I fully understand your point from a LabVIEW architecture point of view.  However I believe the point the OP is making is that anything he drops in a block diagram alongside this DAQmx will be lost in the "forest of unused polymorphic instances".  The VI hierarchy window becomes virtually useless due to visual spam.  Turning on highlighting does not help much imho.  Perhaps a "hide inactive vi's" is an option?

[PJM_Labview]

Aristos,

There are already 3 toolbar buttons for filtering content the are in the hierarchy (vi.lib, typedef, globals) so I really don't see a problem to hide all polymorphic member (lets just add another filter button) . I understand that the result will not be the "real" hierarchy (since we will be missing the polymorphic member), but if this help readability (and it will) this is definitively an improvement.

PJM

[Intaris]

Don't these unused Polymorphic instances get cut from an application when built (Depending on options)?

I would like to see what's actually going to be IN my application and not just what's in memory.

I also think we should be able to turn off the display of VIs which are in memory but not actually being used.

[tst]

Stephen, you're being ganged on, so I figured out I would join as well.

Now only do I agree with the others about not wanting to see the unused poly members in the hierarchy, but I feel that ideally they should not be in the hierarchy at all. They take up memory for no good reason other than the arbitrary fact that that was the way they were implemented.

A better experience for the users would probably be if LV had a way to detect the connector data of the member VIs without loading them into memory and would only load a VI into memory when the user connected it that way. I'm sure this has performance implications as well as having to do the work (for example, I'm sure this has the issue of what happens if the user already has another VI in memory with the same name. Which one do you load? Maybe a poly VI should be a library for namespacing?), but I also know that the current behavior has performance implications as well as annoying UI implications.

As the others said, an easy to implement middle road would be the ability to hide unused poly VIs.

[waldemar.hersacher]

I gave a Kudos, but didn't make a "I agree" comment. Yes please hide the unused poly VIs.

[LabBEAN]

uncalled VI = another instance of the polyVI that is not chosen

Agreed.  Please hide uncalled VIs.

If implemented as a button that also hides "unused" VIs, then don't forget to hide VIs in disabled frames of a Diagram Disable Structure 😄

[AristosQueue (NI)]

 tst wrote:

> Not only do I agree with the others about not wanting to see the

> unused poly members in the hierarchy, but I feel that ideally they

> should not be in the hierarchy at all. They take up memory for no good

> reason other than the arbitrary fact that that was the way they

> were implemented.

See the comment I made on this idea for why the uncalled VIs are loaded into memory. It isn't just an artifact of implementation.  I agree it would be better if we didn't need them in memory, but not loading them does raise some other issues. 

Having said that, even if we didn't load them, I still argue it is correct for any polyVI to show all of its possible instance VIs in the VI Hierarchy Window. Those are the dependencies of the polyVI, and noting that a given VI is under a polyVI is relevant.

Message Edited by Aristos Queue on 07-24-2009 01:58 PM