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

[MichaelAivaliotis]

Why not just select the code and goto Edit>>Create SubVI

[FraggerFox]

We don't need to have a SubVI created just to hide a code. I have mentioned it in the title itself. 🙂

[tst]

This is basically a duplicate of these ideas -

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Collapsible-code/idi-p/1209625

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Macro-in-LabVIEW/idi-p/1095676

[jcarmody]

---

@Fragger Fox wrote:

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.

---

The disadvantage would be that the user can't expand it without blowing up the rest of the diagram.  My first thought was to use a Diagram Disable structure with auto-grow turned off.  What's wrong with sub VIs, anyway?

[AristosQueue (NI)]

Since your VI has reached a level of complexity that warrants breaking parts of it up like this, I think a subVI is perfectly appropriate.

If you're worried about the subVI being called by someone else, put it in a library with the caller VI and make it private. After all, you've reached a level of complexity equivalent to a module.

If you're worried about the performance impact (however minimal) of calling a subVI, mark it as inline.

If you're worried about an additional file, save it into an LLB with its caller.

If you're worried about having to think up a name for the subVI, just call it whatever you would've put in the comment.

What other concerns do you have about having a subVI?

[FraggerFox]

@Aristos:

Its not that "my VI" has reached such level of complexity. I do follow the LV coding conventions, using architectures and SubVIs should be a practice, but not all in the LV community might follow that.  And hence, you might come across a code which was coded by some other programmer, where it would be risky to change anything, as changing on even a single point of code can affect the entire functionality of the module. This was just one of the ideas that struck my mind which made me think "Ok, I don't want to debug or change anything in this mess of wires, so lets just hide the portion which I don't want to look at!"

[silmaril]

I totally agree with AQ.

Please don't implement this idea!

Teaching people to write modular code is hard enough as it is now.

If we give them an additional option for pseudo-modularity, it would be even harder!

[SteveChandler]

You can already do this. I have no idea what this code does.

Step 1: Find some ugly code that you don't want to look at.

Step 2: Add sequence, right click and turn off auto grow.

Step 3 Hide!

Do you see the problem? The problems with any method of hiding code would be the same. I guess when you unhide to edit or view the code LabVIEW could open it in a new window to alleviate the pain. But that is too much like what happens when you use a subvi.

[ErnieH]

It would be nice to get rid of the hundreds of single use VI's in an application. The sub code could be handled just like a subvi, just not saved to yet another file. It would make it easier to reuse code as a single function, save revisions of complex code with worrying about files, file names, cross linking, etc. Plus security, no front panels. What other program do you know of creates hundreds to thousands of separate files for an application.

[AristosQueue (NI)]

> What other program do you know of creates hundreds to thousands of separate files for an application.

Well, the largest single VI hierarchy I've ever heard of is ~20,000 nodes. That's the top end. And I just checked... there are 8148 .cpp and .h files that make up LabVIEW.exe. In all languages that I know of, you generally break a large application into many smaller files.

I've often wished that the file breakdown was even more granular when working with source code control. I'd like to be able to check in and out a single C++ function, rather than a whole file of functions. Eclipse is a JAVA editor that I'm told can do this -- it manages the file system automatically for you, creating a new file for each function.

> Plus security, no front panels.

Lack of front panels... that would be bad. How do you debug? SubVIs you can rerun arbitrarily, and you can test in isolation.

As for the security objection, make the subVIs private to a library. Then they can't be called.