Code frame structure, for use on LabVIEW block diagrams. Helps with keeping code readable and maintainable.

[patjor]

"code frames", similar to decorations, may be used on LabVIEW block diagrams to separate code groups according to function or preference.  Cleanup feature may be disabled within a code frame, allowing the wires, icons, and comments to remain in place.  Wires crossing boundaries can be locked to the boundary as well.   The idea is to allow functional groupings of code without using subvi's, and to prevent cleanup feature from morphing the block diagram layout continually during the development of a VI.

[Mark_Yedinak]

How exactly is this different from a flat sequence structure? Given the flat sequence structure already exists (and is used and abused) if it is lacking any of the cleanup provisions you suggested simply improve the existing structure. Don't create basically a duplicate structure.

[AristosQueue (NI)]

You can already pop up on any structure node and choose "Exclude From Diagram Cleanup".

[patjor]

Mark, The flat sequence structure imposes execution order upon the code inside.  My idea of "code frames" does not change the data flow execution order of the code at all, it only has a visual effect.  Since the purpose of the sequence structure is to control or modify the sequence of code execution, I do not think they should be adapted to make things pretty or readable, I think that would be confusing.  Also, the cleanup action affects the sequence structure contents. 

In reference to my idea, if it is best not to create a new top level structure, perhaps the existing Decoration called the "flat frame" could be enhanced to prevent cleanup of its contents by a selectable property.  Also helpful would be a new feature to create flat frame before, flat frame after, flat frame above, flat frame below. 

As I think about this, my original idea is more of a decoration, so adapting the flat frame decoration for this purpose would be more consistant with the existing LabVIEW features and pallets. 

Anyway, thanks for considering this idea.  : )

[AristosQueue (NI)]

The idea of a decorator structure is one that R&D has considered in the past and rejected as problematic. The convention is that "structure nodes impose execution order restrictions". Any box-like-thing-around-code that does not impose that restriction appears to create confusion among people reading the code. You'll note that the Diagram Disable and Conditional Disable structures both impose execution order. They did not have to do this. We found during user testing that it just created confusion unless those nodes followed the behavior of all other structures.We further found that sections of code that needed to be commented out as a block were mostly -- mostly, please don't think I'm saying always -- ones that didn't change behavior when the the imposed execution order was added. I would guess that regions of code that you want to decorate are also generally ones that can be grouped without changing its behavior with respect to the rest of the diagram.

I won't suggest that we decline this idea just yet -- let's wait and see if it gets more kudos -- but this is one of those ideas that I'd be resistant to unless there's a lot of kudos from the community.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.