It would be handy if I could set front-panel like groups on the block diagram. It would make laying out readable code a bit easier. Not a huge deal, but a nice touch.

Hi,

what about creating sub vis for each "block diagramm group"
making the code more readable

-timo

Yeah, but this would be an extra option. I like the idea (I've never tried it, so I don't know if it's already possible or not)......

Just my 2c

Shane.

Shane and Chris,

My first response is "I don't like ideas that can encourage bad coding style." So I have to ask, "What value do you see in this idea and how would you envision using it?"

Curious,

Ben

I don't think it would encourage bad coding style. I frequently wish for Grouping on the block diagram so I can move bits of code around together without doing a multi-step select-an-area-then-deselect-individual-items-that-I-don't-want-to-move gymnastic. There are plenty of times when I'd use that functionality to improve the layout of code. Besides, if LabVIEW is a graphical dataflow programming environment, and we have standard tools for Grouping on the front panel, why wouldn't we have the same tools on the block diagram?

I've often wondered, though, if there's some technical or usability reason why Grouping isn't available on the block diagram. It's reasonable to think that it's been explored at some point by NI. I'd be interested to know if there's an inside story behind it.


There are scenarios where that isn't enough.

Example 1: Virtually every subVI I create has Error In/Error Out terminals, and an Error Case Structure surrounding the code of the subVI. I would really like to be able to group the Error In/Error Out terminals with their tunnels on the Case Structure, so that I can easily move them up or down. This is a routine I go through for almost every subVI I create.

Example 2: I might have a series of LVOOP class VIs that happen one after the other. In this case, I might not want to create a subVI containing methods from all those classes because it would (A) have a ton of terminals, and/or (B) create a subVI with a lot of class dependencies that I don't want.

Creating a subVI also won't work if the VIs you want to Group are located both inside and outside some structures, but you don't want the structure to be part of the group.

You're right, however, that creating a subVI is a solution some of the time.

Almost every feature can encourage bad coding style


For exactly the same reason(s) I use it on the front panel - for convenience. I like to group related items, so I don't have to do the multiple-click-select. It'd also be useful to "attach" free text labels (ie: documentation) to code.

Thanks. I can relate to the selection gymnastics issue.

Two technical complications come to mind.

1) If you open a diagram on a mahcine that is using a larger font that what you used at development time, the grouping would add extra work to clean-up since ...

2) Ctrl-shift-drag when performed inside a set of grouped objects would... A) deal with the group as a single object, or B) just blow-up the group?

Ben

I agree (obviously judging by my previous response).

It's enivitable that, due to either space constraints or pure optical luxury, different "groups" of block diagram objects get to overlap. Moving that "group" is, as Justin says, a multi-step operation. We have a graphical language. The visual representation (orientation of objects) has a lot to do with understanding how the code works. We (I'm not quite sure who "we" are, but either way....) automatically group parts of code with similar functions visually on the BD, so why not lock their positions to each other? This allows us to pull the whole code section somewhere else without either destroying the arrangement or needing to do a multi-step move.

Another case I would like to address is inherited code..... I can imagine some cases in which code would have been MUCH easier to clean up if I had this tool available.

I also think it's something NI HAS tried. I too would be interested in knowing if this is even probable....

@Ben. I think as per normal usage, a group behaves as a single unit.

Shane.

This post has been edited by shoneill: Mar 5 2008, 03:25 PM

A little clever application of scripting could solve this issue. Sounds like a good code challenge.

and guns don't kill people, but people do...

"Hey punk, put down the mouse, step away from the test station, and no one gets hurt..."

If I'm grouping a large number of components in which it makes logical sense to put in a sub vi that is definitely the way to go. Usually when I'm wishing for it I have a small number of components (~3-5) where adding a sub vi would add to the overall complexity of the project. For instance, in my current project I have a sub vi I use in several places. The output of the sub vi is usually immediately wired to an unbundle by name so I can get the data I need. For readability it makes sense to group the sub vi to the unbundle control to keep them aligned, but it makes no sense to create a series of sub vis for each unbundle combination I might need.

*Ding* You're it! I'm looking forward to seeing what you come up with.

Ctrl-shift-drag makes a copy of whatever is selected. Selecting an item in a group selects the entire group. Therefore, ctrl-shift-drag copies the entire group, just like what happens on the front panel. (That's how I would deal with it anyway.)

This post has been edited by Daklu: Mar 7 2008, 10:21 PM