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

[tst]

Sorry, I'm still unconvinced.

I don't know the actual details, so I'm obviously not qualified to comment on the implementation, but I can say how I see this, as a user, which might help explain it. I think you'll find most other users feel the same, as evidenced by the posts and kudos:

Poly VIs are an ease of use feature. Nothing more. They allow you to select from a list of options either manually or automatically. This is a great feature.

However.

As the programmer, you only care about one single VI. That's the VI that's actually used. Once a VI was selected I don't care about any of the other VIs. I don't need them in memory (LV might. I don't. I still feel that's an implementation detail). I certainly don't want to see them in the hierarchy window when I'm trying to look at the structure of my app (not dependencies. That's what I have the project window with its two tabs for). As far as I'm concerned, the app should actually continue working even if only the instance VI remained.

P.S. Regarding your question on the other thread - yes, if we want not to have the VIs in the hierarchy, I don't have a problem with LV reading the data from disk every time the user interacts with the VI (not just random clicks on the diagram). However, as I said, I'm not qualified to give a real answer and I agree that my assertion about the implementation was poorly worded. 

P.P.S. Some of the issues with poly VIs would be better addressed with another solution (e.g. a typeless wire adapting a type at edit time), but I'm sure LV R&D already knows that and work accordingly. Not to mention that each solution would have its own set of problems (e.g. where is the actual machine code saved for each instance of the typeless wire VI).

[tst]

Also, to better illustrate this, here's a simple (if contrived) example:

As you can see, this is a simple piece of code which uses 6 OpenG VIs. OpenG VIs are often polymorphic, thus these 6 VIs result in a total of 218 VIs added to the hierarchy.

Here's what part of the hierarchy window looks like. Imagine what happens when this is part of a real app where you're trying to actually understand what's happening and you'll see why this becomes a problem.

I suspect that part of the reason that NI people don't feel this is as much is that almost all the polymorphic VIs they use are in vi.lib, and that's easy to hide in the hierarchy window.

Message Edited by tst on 26.07.2009 06:21 PM

[Intaris]

The abovce example renders the VI hierarchy view useless to every body except AQ.

So we change it and introduce a new INI key "Superfunkyhierarchystuff" for AQ..... 😄

[AristosQueue (NI)]

tst wrote:

> As the programmer, you only care about one single VI.

Which programmer? The one using the poly VI or the one developing the polyVI. My argument is that for the polyVI developer, showing all the instances is correct and useful. 

[tst]

> My argument is that for the polyVI developer, showing all the instances is correct and useful.

Great. So let's make life easy for the Poly VI developer (who finished writing the VI three years ago) at the expense of every other LabVIEW user throughout history (including the Poly VI developer at any time other than the time of writing the poly VI). That sounds reasonable.

As was said, a reasonable middle ground is adding the poly VIs to the things which can be hidden.

[Jim_Kring]

What I want the VI Hierarchy window to do is show me "My Application's VI Call Hierarchy".  The use cases for seeing all poly instances are probably limited to developers creating poly VIs.

One thing that this discussion points to is that there are (and should be) better tools than poly VIs like LVOOP dynamic methods (polymorphism) and type adaption.  If we used/had thes, then we might not even need poly VIs as they exist right now.

In the short term, I vote for adding a filter to the toolbar that shows/hides uncalled poly instances and have it hide them by default.

[Omar_Mussa]

I agree.  There should at least be a toolbar button to hide unused poly instances.  Most LabVIEW developers probably don't need to see poly instances that they are not using.

[Jim_Kring]

Sorry for all the repeat postings.  I never got visual feedback that the comment was successfully posted, and had no idea that there were several pages.  I guess this usablility issue reported.

Moderator: please feel free to delete my duplicate comments.

[AristosQueue (NI)]

> As was said, a reasonable middle ground is adding the poly VIs to the things which can be hidden.

That does seem like a reasonable compromise.

[InternationAL]

I hope the default for the "Hide Unused Polymorphic Members" button is to hide the polymorphic members.  Also, the button should remember whatever setting you happen to have it on between application launches.  If you are one of those people who constantly makes polymorphic VI's, it would probably be nice to click that button once to have it show everything, and not have to click it again until you're done with that task.  Conversely, if you are 99.9% of LabVIEW programmers, and you are not interested in the polymorphic members, you should be able to click once (or hopefully never, if the default is to hide members) and have polymorphic members stay forever hidden.

MODERATOR:  I had duplicate images in my image gallery for some reason, and I deleted one of the duplicates.  It happened to be the one that was linked to by this idea.  If you could use the other image for the missing image above, I'd appreciate it.  Thanks.