Allow Hide/Unhide of code inside Block Diagram, without using SubVI

[FraggerFox]

This functionality is inspired by Microsoft Excel's hide/unhide functionality.

Suppose we have a code like this:

User should be able to select the portion of code he needs to hide, and be able to add a comment on that, something like this:

After he enters the comment, the block diagram would be shown something like this:

Similar option should be there for "Unhide".

The advantage of this would be the user can group a huge block diagram (for example having a flat coding structure) according to the functionality it does, without adding SubVIs to the project.

Regards,

FraggerFox

[Ray.R]

---

SteveChandler  wrote:

Ray, I agree completely. I am just pointing out that it is already very easy to do what the idea author wants to do. In fact I wouldn't be terribly surprised if this were declined on the basis of "this functionality already exists in LabVIEW" I have never used the technique that I described and would fire anyone who worked for me if they did.Same goes for if they use this new feature should NI implement it. I won't loose any sleep worrying they will.

But that being said saving a subvi as part of the calling vi is an interesting idea. I would almost support an idea like that but it is different than what Fragger Fox was asking for. It is still a subvi but saved in the same file as another vi. I can't think of any reason I would want that but it sounds interesting nonetheless.

---

There seems to be 2 things mentionned in this thread..  2 quite different things...  Maybe I misunderstood something, so to clarify my understanding....

1.  Ability to hide code:

To me this would be similar to placing wires or objects under other objects.  Or the ability to render invisible Controls or Indicators on the block diagram.  Hiding code is extremely bad in any language.  How do you debug or read code that you cannot see?  Do I need to say anything else?  😉

2.  Ability to place code in an area which is like a sub-vi but still within the same VI:

For those familiar with TestStand, this sounds a bit like the ability to create sub-sequences within the same sequence file.  I won't go into the details..  Basically, the code is not hidden, but located in a different area from the main code.  It requires to open that portion of code to see it.  Would I want to see such a feature in LabVIEW?  I don't know...  I don't know what that would mean as far as being able to read and understand code.  I see enough code obfuscation as it is in LabVIEW.  Why do I not feel the same way with sub-vis?  Well, I consider that each sub-vi should be able to run on its own.  Sub-code may not be able to run on its own and how do you debug this?  This would be similar to a crazy feature that was talked about many years ago where you could zoom in and out of the block diagram.  That would simply promote spagetti code, more obfuscation and lead to unreadable code...  There's nothing wrong with sub-vi's.  I'd be on the fence leaning away from this idea...  But maybe it is not that bad...  It might actually look like a formula node...  So what would be the difference...???....Back to neutral on the fence...  I would have to think more about it... But what would be the benefit over a sub-vi?  Saving a file on the hard-drive?  no..  not a benefit..  If you use a LV project correctly, then I do not see a benefit...

[Ray.R]

Ray, I agree completely. I am just pointing out that it is already very easy to do what the idea author wants to do. In fact I wouldn't be terribly surprised if this were declined on the basis of "this functionality already exists in LabVIEW" I have never used the technique that I described and would fire anyone who worked for me if they did.Same goes for if they use this new feature should NI implement it. I won't loose any sleep worrying they will.

But that being said saving a subvi as part of the calling vi is an interesting idea. I would almost support an idea like that but it is different than what Fragger Fox was asking for. It is still a subvi but saved in the same file as another vi. I can't think of any reason I would want that but it sounds interesting nonetheless.

[MichaelAivaliotis]

Is there a way to post a negative vote so we can bury this idea to oblivion?

[AristosQueue (NI)]

> Is there a way to post a negative vote so we can bury this idea to oblivion?

No. Deliberately.

If it gets enough Kudos to be considered, then LV R&D will consider it. If it turns out that a feature only supports one customer segment and not another, we try to find ways to make the feature have lower impact on the group that doesn't want it. Sometimes we're successful, sometimes not, but we do try. In any case, the "only positive kudos" is a deliberate philosophy of the Idea Exchange.

At 5 kudos, you're in little danger of this idea moving forward.

[Ray.R]

I like Michael's idea...  Maybe the Idea Exchange should have "yeah" or "nay" buttons instead of relying on Kudos.  After all, if 100 people vote for a bad idea, it does not make it a good one.  Maybe there are 1000 people who think some idea is bad and those votes remain unheard or invisible...

Michael, since it was your idea, do you want to post that suggestion?

[Darin.K]

At the risk of giving free pub to an idea I dislike, http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-the-OPPOSITE-of-KUDOS-ie-BOO/idi-p/1280260

[AristosQueue (NI)]

>  After all, if 100 people vote for a bad idea, it does not make it a good one. 

And if 100 people vote against a good idea, it does not make it a bad one. The Kudos are not the arbiter of whether an idea is good or bad. It is an arbiter of whether an idea is *worth investigation or not*. Here's a prime example:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Default-Option-Do-NOT-Place-Front-Panel-Terminal-as-Ic...

322 kudos for this idea. Definitely worth investigating. And NI did investigate it, redoing the interviews with users brand new to LabVIEW. And as a result of that, NI declined this idea.

That's the key of kudos -- enough people want us to try to work on the problem. The exact solution proposed in the idea may or may not pan out, but the area is one that bugs enough people that they took the time to vote for the idea. That's why negative kudos is a bad concept -- it would hide something that does need *something* to be done. Now, having said that, when we decline a high kudos idea without doing anything -- as in the example above -- you'll note that in the explanation of the decline, there's a comment about continuing to work on another aspect of the problem. We still know there's an issue there.

[Ray.R]

I should have emphasized that I did not mean the "nay" cancels the "yeah".  You'd have total "Yeah" versus "nays".. 

Example:  200 votes...

120 yeahs

80 nays

not the same as 40 Kudos...  (or 40 yeahs).  That way, you still get to see that it is a feature worth investigating, but keeping in mind that there is a relatively strong support against the idea...   Blending into the weight....

But then again, that might just bring up an old fight which is what Kudos was meant to avoid 😉

[Ray.R]

Thanks Darin,

That was an interesting thread...  Maybe we should continue our discussion over there..  🙂