Comment Structure or Comment Box (surround a group of VIs with a box and comment)

[Petru_Tarabuta]

I sometimes wish to surround a group of VIs with a 'comment box' that explains that particular code section, for example to explain how the VIs interact with each other or why they were placed in a certain order.

To simulate this, I use Flat Sequence Structures, Flat Frames or Diagram Disable Structures with empty 'Disabled' cases (screenshot below).

All methods are workarounds. It would be useful if there was a 'Comment Structure' or 'Comment Box' that was essentially a Flat Frame with an attached sub-label diagram.

• The Comment Structure should be compiled-out and have no effect on the compiled code (unlike the Flat Sequence Structure)
• The Comment Structure would not have any 'Disabled' cases behind it
• The border of the Comment Structure should be as thin as possible. For example, the border of the Flat Frame seems too thick when I use that workaround.
• I'd be happy if the Comment Structure consists of a single box and there was no option to 'Add Frame' like there is with the FSS, even though I sometimes use a multi-frame FSS to simulate back-to-back Comment Structures (like in the screenshot above).

A similar question was posted in the following thread: "Is there a way to put a comment box around a piece of code..." https://forums.ni.com/t5/LabVIEW/Comment-code/td-p/40568 

Thanks!

[wiebe@CARYA]

Another workaround is to get a raised frame from your front panel palette, and drop it (or copy paste it) on the block diagram.

The decoration won't have a diagram label, so it's just a workaround. But other then the label, I think it does what you describe. And it had been used for years.

[AristosQueue (NI)]

> The Comment Structure should be compiled-out and have no

> effect on the compiled code (unlike the Flat Sequence Structure)

I proposed this part of your idea in 2009. In 2017, I had to decline my own idea after lots of feedback: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Both-disable-structures-should-have-less-effect-on-di...

The current standing decision is that no enclosing box* will ever be introduced to LabVIEW that does not follow dataflow semantics.

* I say "box" because it would not -- by definition -- be a "node" or "structure" since it would not behave with the single most important aspect of a node in G. We would have to introduce a whole new scripting hierarchy. See "Liskov Substitution Principle" for inheritance discussion.

You said:

> All methods are workarounds. 

The majority of users disagree with you, and, these days, so do I. If difference in compilation is off the table (see above), then there is no difference other than draw style between what you are asking for and the sequence structure, and draw style isn't worth the introduction of a whole new node.

With alternate compilation and alternate draw style off the table, I don't think there's anything left to this idea. You would need to propose a difference in run-time behavior to justify a new structure node... the edit-time behavior of disallowing adding frames falls under the heading of, "If you don't want to use that, don't use it." 🙂

[wiebe@CARYA]

If FP decorations had labels, this gest of this idea would be completed.

The decoration wouldn't actually contain anything, and it doesn't even grow if ctrl+drag and alt+ctrl+drag is used...

[crossrulz]

I think all we would need for this is to have direct access to decorations on the block diagram.  So if we had a new decoration that was just a Flat Frame that had a text input associated with it, we have what the OP is looking for.  It isn't a structure, so it has nothing to do with data flow and sub-diagrams.  It is just a way to visually break up parts of your code.

[wiebe@CARYA]

Of course there will be other benefits if decorations had (hidable) labels.

make-decoration-labels-work\

give-decorations-a-label-property-to-address-and-modify-them

[AristosQueue (NI)]

> It is just a way to visually break up parts of your code.

Therein lies the problem: it's a visual language. A visual way to break up parts of code gets interpreted by too many users as part of the code. Comment labels don't look like a functional node... a box does.

The community had this discussion often for the diagram disable structure. 🙂 And back then, I was on the other side. I've been worn down to accepting this as Truth. 🙂

> So if we had a new decoration that was just a Flat Frame that

> had a text input associated with it

A flat frame drawn on top can drift away from its contained code. If we start promoting frames on the diagram -- something few users even realize is possible -- we will immediately get requests for the frame to actually include the nodes... autosizing... moving with... until it has all the syntax behavior of a structure node. If it has the syntax behavior, it's going to need the semantic behavior. And now we're right back to "use a sequence structure".

[crossrulz]

>A flat frame drawn on top can drift away from its contained code.

Yeah, and so can comments.  All I (can't say for certain the OP) am asking for is a documentation tool.  We all know documentation becomes stale unless actively updated.  Same goes for this decoration.

As another example, straight from the USB-845x I2C examples by NI, see this post: https://forums.ni.com/t5/LabVIEW/MCP23017-I2C-LabView-HELP-PLEASE/m-p/4072791#M1170486 

[AristosQueue (NI)]

> Yeah, and so can comments.

This is exactly why the attached comments were introduced. Attached comments remain attached.

> All I (can't say for certain the OP) am asking for is a documentation tool.

And all I'm saying is that the sequence structure meets every requirement for that documentation tool that has ever been given to R&D other than the "things inside should not run as a block", which, as explained above, is off the table for good reasons.

[donkdonk]

[..] Another workaround is to get a raised frame from your front panel palette [..]

Learned something today 😃. Didn't know you could do that.

On the Block Diagram under Programming/Structures/Decorations you have a limited set of decorations.

I used that exactly for the purpose mentioned here.

But as soon  as I placed them, I realized that indeed it looks like part of the code.

I tried using attached comments, make them 'artificially' larger with spaces, CR, to enclose a piece of code.

But that didn't last long: too much a hassle interfering with your code, not able to lock it, etc.

Hard to imagine that developers are not able to come up with something that does not look like part of the code, something like a text balloon, encircle. And you could still attach it to something, so it does not float too far away. 

[..] Therein lies the problem: it's a visual language [..]

Just because it is a visual language, you should be able to comment a section. Just as you would with a pen(cil): encircle a part and write your comment.

I understand a lot of the arguments against, but I am not convinced.

That being said: the purpose of the current comments (that can be attached using an arrow) is clear, also for new users. So that was really an improvement.