Add Frame After and Split Frame in Sequence Structure

[rex1030]

Currently if code is already written, it is difficult to put it into a sequence structure, splitting the code into multiple frames, without breaking wires. It would be great if when I right clicked on the edge of a sequence structure and chose "add frame after" it allowed me to draw the next frame before placing it.

I would also like to be able to selectively split an existing frame up

Wouldn't this be easy and intuitive?

I tried to look for other ideas like this on the exchange and all I found was this but he was a little confusing in explaining his idea and how would it work. 

[Dennis_Knutson]

Sorry, but personally, I would be opposed to anything that would encourage anyone to use the sequence structure. There is certainly nothing in the above example that would require it's use. I would, however, kudo a suggestion to remove it.

[JackDunaway]

@Dennis: Needing a single sequence frame to group code execution is inevitable - we can't get rid of the structure altogether (you may gain a minority argument on eliminating the multi-frame FSS). Other than that, I share the same sentiment.

It's a good Idea, and I nearly Kudoe'd it, but I maaay be able to use the feature once a month... about how often I'll drop the unavoidable FSS. And for every one time I am able to use the feature, how many of the illustration below would be created around the world? (Hey Dennis, have you ever run across this programming paradigm on the LabVIEW board? )

[rex1030]

Of course I concede that there is no reason to use the sequence structure in the above code example. It was just the code I was working on when I thought of posting the idea I had had for a while on the idea exchange. People should undoubtedly try to avoid sequence structures (especially in labview coding example VIs).

That doesn't mean that making them work better is a bad thing though. I doubt preventing broken wires when adding or splitting frames would encourage anyone to use the structure when they wouldn't have otherwise.

[Manzolli]

Agree 100% with JackDunaway. The idea is not to encourage using sequences, is to make its edit process easier. Sometimes we have to use it, then shoud be as easier as possible. It's nonse making something hard to work with just to avoid it's use instead of teaching good programming practices.

The kind of comments made by Dennis Knutson make people afraid of speaking out. Eve though, like JackDunaway, I was not kudoing the idea, but I did just to support rex1030 I kudoed it!

[CrystalTech]

If there was no need for the sequencer, I would agree.  I do not like having to use it.  However, in times there are no other better alternatives to force a specific sequence,  having this feature would make it much easier to use.  Kudos!

[Neil.Pate]

Kudos here. Just an hour ago I was trying to find a bottleneck in some code and dropping tick counts all over the show. As it was pure LV code (with no error cluster) I was timing there was no easy way to add in dataflow timing. So it had to be done using sequences.

This was purely for debugging/understanding, and being able to do as the idea suggests would have saved me some time.

[muks]

I agree and felt the need though rarely. Definetly a helpful feature considering the ways we will follow to bring the required part into the new frame.

[JackDunaway]

More generic Idea that applies to all structures.

[SteveChandler]

I'm a few months late but Kudos! My first thought was to just move on. But after following Jack's link I kudoed the more generic idea and came back to kudo this one. If the generic idea were to be implemented it should definately include the structure that so many detest but like a a roll of duct tape can be handy at times. Especially in those situations that nrp mentions.

[gerh]

Years later...

I think this thread should kept alive, because it is a really strong feature. This is also true for the idea Jack linked. How Manzolli noticed, there are some cases where the flat sequence is necessary and important. Otherwise the code becomes undeterministic because of race conditions. Connecting the error clusters into a line doesn't work in every situation, how you can see in the example below.

In this example the error coming out of the VI's needs to be bypassed, because the VI in the third frame must not be affected by an error. On the other hand, for synchronization issues, it has to wait until the VI's of the secon frame have finised executing.

By the way: Now it would be possible to merge the first and the second frame. Last times I applied accidently the merge to the wrong frame and saved, but going the way back was not that easy...