Named Frames in Stacked Sequence Structure

[InfiniteNothing]

To improve the built in documentation of the code, and to make selecting the right frame easier, I suggest that we should be able to name frames in a stacked sequence:

Preemptive defense of stacked sequence structures: A stacked sequence structure takes up less room on the block diagram than a while loop and a case structure. They serve a very specific function that tells code readers that there's not going to be any funny buisness in jumping around from frame to frame. You can't accidentally write an inifinte loop, skip frames, etc. Don't let the abusers obstruct the legitimate use of these structures.

[RavensFan]

There is just no need for it when you can put a free label at the top of each frame.

[InfiniteNothing]

But, currently, when you click the downwards pointing triangle, you don't get a list of the frame names.

[GregR]

What if instead of being in the selector visual, the text used something like the Integrated Structure Labels idea? Any structure with a selector drop down might include the label text for each frame in its menu. 

[smercurio_fc]

I would agree that the use case for this is pretty small. Once could argue that a Flat Sequence could be used instead (yes, I know the limited advantage of the Stacked Sequence about it "taking less room"). While I can see that it would be neat, my response is basically "meh...".

[Ray.R]

Shouldn't you be using a State Machine instead?  ie Case Structure with a Type Def selector...

I do not see any benefit from this. As a matter of fact, I oppose the use of Stacked Sequence Structures.  They are horrible to support dataflow. 

Bluntly put:  It's a bad idea...

[Darin.K]

If there is one thing we can all agree on, it seems that the current incarnation of the stacked sequence structure is fundamentally flawed.  NI seems to have some strange attachment to it, and the hope that it is so bad that nobody will use it, but that it will still be there.  Unfortunately, it seems like it will simply be withering on the vine for some time to come.  I suggest that it is time to you-know-what or get off the pot, and decide either to fix it or remove it entirely.

To me, the sequence local implementation is terrible.  Some method, like a hybrid shift register which keeps left-to-right flow is a necessity.  Without a fundamental fix, ideas like labels are simply putting lipstick on a pig.  I would use improved SSSs in limited cases to save space, for example when scripting or using .NET methods.  A sprawling, already serialized process could be in a SSS instead of taking up two monitor widths.  In fact, probably the last SSS I used was in LV2 on a Mac with a screen about the size of my hand which made space savings very important.

Calling the State Machine a replacement is similar to saying that the Value property node is a replacement for a local variable.  You may feel better about it, but in the end you are paying a performance penalty.  A well-formed SSS should be simply a remapping of the code, with no penalty for comparisons and fully optimizable by the compiler.  There are real, measurable, (often neglible) time penalties for case structures with more than two cases. 

To reiterate, my defense is not of the current, useless SSS, but rather what the SSS could be.  I fully support two options, dump it or fix it.  I strongly disagree with the current do nothing and hope it fades away policy.  Once that decision is made, then it is time to consider ideas such as this one.

[altenbach]

I think I can manage without that feature. 😄

[tst]

> Some method, like a hybrid shift register which keeps left-to-right flow is a necessity.

That idea did not seem to be too popular - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Stacked-Sequence/idi-p/918243

[Darin.K]

That idea was not quite what I would envision, but it demonstrates the silly notion of "discouraging" users.  If you want to discourage its use, get rid of it already.  It is like my toolbox, I carry it around so every tool in there had better be worth its weight.  The SSS right now is not worth its palette real estate, so if you aren't going to fix it, then nuke it.

Many people are entrenched in the idea of the SSS as a dataflow substitute, I actually see it more as a potential tool for adding a third dimension to the BD.  As to the potential for abuse, the fact that someone else can cut their foot off with one does not deter me from buying and using my reciprocating saw.

[Mark_Yedinak]

Darin,

I understand what you are saying and I would argue that even with improvement the stacked sequence structure should be ditched. From a code readability perspective taking that long string of serialized code like you mention would be better suited to be put into a subVI. The icon as well as the documentation is better. It is more meaningful on the calling BD. When opened it is more readable than a SSS. As for performance you could simply inline the subVI and you wouldn't have the overhead of the subVI call. In my opinion there is no need to improve or even keep the SSS.