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

[silmaril]

I think this is a case of worlds colliding.

We have one world of people who just want to build their laboratory application with a few clicks. In this world, nobody cares about source code control of software engineering aspects. Things just have to bring results quickly.

The other one is the world of software engineers who use LabVIEW as a tool to develop professional software, which includes many aspects of software engineering. Things have to follow defined ways to make sure you don't end up in a mess.

The first group would like anything that makes things look simpler, even if it's just hiding complexity.

The second group prefers accurate definitions and structures that support their engineering process.

The problem is that NI tries to develop LabVIEW as a product for both worlds at the same time. This leads to trade-offs on both sides.

[ErnieH]

I am just saying, you don't want a new file for every little function in your program. Having an embedded function for glue logic would be desirable (at least to me). That way I could save complete functions in one VI. Copy it anywhere without cross linking or name problems. As far a source control, larger complete VI's would be easier for me to control instead of lots of little Vi's that change. I am asking for the choice to embed small Vi's (mainly non-reusable parts of a program) into larger ones, with the same editing capabilities as Vi's. It is no different than what we have now, just fewer files and (at least for me) better ways to control my code. An example, I have a fairly complex function (with 20 sub VI's)I wrote for a program. I want to copy it to another program, modify it, and use it. If it were one Vi, it would be much easier for me to do that. It would look just like the code we write now when you open it. No additional problems with source code control. Would not hide complexity any more than a normal subvi. No additional mess. Just my two cents.

[CTF]

>silmaril on 03-25-2011 05:20 AM

>I think this is a case of worlds colliding.

> 

>We have one world of people who just want to build their laboratory application with a few clicks. In this world, nobody cares about source code >control of software engineering aspects. Things just have to bring results quickly.

>

>The other one is the world of software engineers who use LabVIEW as a tool to develop professional software, which includes many aspects of >software engineering. Things have to follow defined ways to make sure you don't end up in a mess.

>

>The first group would like anything that makes things look simpler, even if it's just hiding complexity.

>The second group prefers accurate definitions and structures that support their engineering process.

Bingo.  As a test engineer/experimentalist, my trend is toward the first group.  My maxim is first make in work, then worry about making it pretty IF there's time.  Modularity & reuse is low on the priority list.  Code is often cobbled together and/or modified during the execution of an experiment, which is facilitated with a a graphical program like LabView, but but can produce some pretty ugly block diagrams.  Forcing "proper" programming techniques and strategies would be a hindrance  is such situations.

On the fence about Kudo-ing this idea, I can see how some might find it useful,  but I'm not sure how I would use this with my programming style (but I use <gasp> local variables and <gasp> stacked sequences <gasp> when the situation warrants.

> Aristos Queue on 03-23-2011 11:36 PM

> <...>What other concerns do you have about having a subVI?

Some times the offensive code has a front panel terminal in a loop where the functionality will be affected by making it a subVi. 

Another time a piece of code had too many input/outputs to be practical

Fixable, sure, but the returns don't justify effort.

[CTF]

> 

>We have one world of people who just want to build their laboratory application with a few clicks. In this world, nobody cares about source code >control of software engineering aspects. Things just have to bring results quickly.

>

>The other one is the world of software engineers who use LabVIEW as a tool to develop professional software, which includes many aspects of >software engineering. Things have to follow defined ways to make sure you don't end up in a mess.

>

>The first group would like anything that makes things look simpler, even if it's just hiding complexity.

>The second group prefers accurate definitions and structures that support their engineering process.

Bingo.  As a test engineer/experimentalist, my trend is toward the first group.  My maxim is first make in work, then worry about making it pretty IF there's time.  Modularity & reuse is low on the priority list.  Code is often cobbled together and/or modified during the execution of an experiment, which is facilitated with a a graphical program like LabView, but but can produce some pretty ugly block diagrams.  Forcing "proper" programming techniques and strategies would be a hindrance  is such situations.

On the fence about Kudo-ing this idea, I can see how some might find it useful,  but I'm not sure how I would use this with my programming style (but I use <gasp> local variables and <gasp> stacked sequences <gasp> when the situation warrants.

[CTF]

> Aristos Queue on 03-23-2011 11:36 PM

[CTF]

> <...>What other concerns do you have about having a subVI?

[CTF]

Some times the offensive code has a front panel terminal in a loop where the functionality will be affected by making it a subVi. 

[CTF]

Another time a piece of code had too many input/outputs to be practical

[CTF]

Fixable, sure, but the returns don't justify effort.

[SteveChandler]

ErnieH: I am just saying, you don't want a new file for every little function in your program. Having an embedded function for glue logic would be desirable (at least to me). That way I could save complete functions in one VI. Copy it anywhere without cross linking or name problems.

Have you tried the sequence structure hack? You can shrink down the sequence structure and put a label over it. If you want to reuse the functionality just select the sequence, copy it and paste it elsewhere. And I just checked. When you resize the frame to edit or look at the code, the code remains arranged the way it was before you shrunk it.

Sure it is a hack but if NI were to implement this it would only eliminate your having to size down the frame. I'm just saying this because with all the ideas here I doubt this one will make it to the top of the priority list. But of course I don't work for NI and could be totally wrong and we will see this in LV2011. I just wanted to let you know that you can already do something very similar.

In fact you could make a non functional vi that contains many of these reusable functions.

I do not recommend programming like this. I recommend using a library of subvis instead.

[SteveChandler]

ErnieH: I am just saying, you don't want a new file for every little function in your program. Having an embedded function for glue logic would be desirable (at least to me). That way I could save complete functions in one VI. Copy it anywhere without cross linking or name problems.

Have you tried the sequence structure hack? You can shrink down the sequence structure and put a label over it. If you want to reuse the functionality just select the sequence, copy it and paste it elsewhere. And I just checked. When you resize the frame to edit or look at the code, the code remains arranged the way it was before you shrunk it.

Sure it is a hack but if NI were to implement this it would only eliminate your having to size down the frame. I'm just saying this because with all the ideas here I doubt this one will make it to the top of the priority list. But of course I don't work for NI and could be totally wrong and we will see this in LV2011. I just wanted to let you know that you can already do something very similar.

In fact you could make a non functional vi that contains many of these reusable functions.

I do not recommend programming like this. I recommend using a library of subvis instead.

[Ray.R]

Giving people tools to create or hide bad code is a BAD idea..

I also totally agree with AQ.  So please DO NOT implement this idea!

Two wrongs never make a right!!

[ErnieH]

Don't want a hack. If the capability to embed the subvi into the upper level was available, I would use it, as well as a lot of other people would, I would guess. It is not hiding bad code, it just gives people more options to save and keep code together. It is no worse than creating a subvi. My take is it would act just like a subvi without the additional file(s). That is it. I agree creating a hack would be a bad idea.

[silmaril]

So you would like to have the comfort of sub-VIs, but with everything packed in one large file?

Why not use this great new feature of LabVIEW 2010, called Packed Project Libraries?

[SteveChandler]

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.

[jcarmody]

I suggested using a Sequence structure this way on the LabVIEW forum back in 2009, as a joke.  The response was so bad that I had to ask the moderator to add a note to my post. - here

[SteveChandler]

I have heard of people actually using this technique. So it's YOUR fault Should this be called the "Jim Structure"?

But I am starting to lean towards supporting this idea. WHAT?

Sometimes a good idea can sound like a bad one by the way it is phrased. I already didn't like this when I saw the "Inspired by Microsoft Excel" part.

But if different words were used it could have come accross much better. Other words could have been used like "Embedded Local Sub VI" or something. You would select some code and "Create Local SubVI" and it would behave just like create subvi. You just don't have to save the file. There would be an option for the embedded subvi to "Convert To SubVI". This could serve as a tool for refactoring code.

Something like this may actually encourage good programming practices for new users. For new users creating a subvi is tedious. You have to find the controls in the pallettes, arrange them on a front panel and wire to a connector pane. These things are so easy with experience that we forget what it was like when we were learning.

It was already pointed out that this may be a duplicate of the "macro" suggestion.

But while I said I am starting to think I might support this idea I have not convinced myself yet.