Bug Report: Trying to attach a free label arrow to a Sequence Local results in...

[X.]

Try to pull the arrow from the free label below and attach it to the Sequence Local:

Unfortunately, arrows don't stick to Sequence Locals even if they "Sense" them. By sensing, I mean that the free label's border switches to a "marching ants" pattern, as it does whenever a possible target is approached.

Nonetheless, try to release the arrow when above the Sequence Local. You'll get this:

The arrow jumps to the upper left corner of the diagram, where you cannot grab it and bring it back.

You can however grab the end attached to the label and release it, which vaporises the arrow.

Note 1: it doesn't matter where the Sequence Local is located within the Sequence.

Note 2: I have occasionally been able to select a Sequence Local (i.e. have its border switch to a marching ants pattern), but upon releasing the arrow, it snapped to the upper-left BD corner just as well.

Note 3: If you extend the BD to the left, you'll see this:

A floating arrow! Whose pointy end you cannot grab, unless you expand the Sequence so that it encompasses the full length of the arrow.

Tested in LabVIEW 2013 SP1 64 bits in Windows 7.

[billko]

How about attaching it to the constant instead?  That's how I probably would've done it... if I used stacked sequences.  I wonder how it would work if you tried attaching it to other things like the case selector in a case structure or an event data node in an event structure or maybe a shift register?

[mikeporter]

The best solution to your problem is to click on the edge of the sequence structure and press the "Delete" key. Problem is gone and the quality of your code has taken a giant leap forward.

Mike...

[billko]

---

@mikeporter wrote:

The best solution to your problem is to click on the edge of the sequence structure and press the "Delete" key. Problem is gone and the quality of your code has taken a giant leap forward.

Mike...

---

Maybe that is NI's way of showing you the code is way out of bounds.  😉

[X.]

Beware, I think irony is not tolerated on this forum.

This being said, it might well be that the Sequence Structure not being a recommended feature, it gets very little attention during debugging.

It is a bug nonetheless, and any inference on my programming style based on this report is really the author's own concern...

[billko]

But you got me curious.  I think I'll try this on some other structures, see what happens...

[billko]

The results were pretty boring... but I noticed that the sequence structure arrow points to the origin of the BD.

[X.]

Thanks for confirming. Now, maybe a blue guy will notice the need for a CAR... or maybe not.

[mikeporter]

---

@X. wrote:

Beware, I think irony is not tolerated on this forum.

This being said, it might well be that the Sequence Structure not being a recommended feature, it gets very little attention during debugging.

It is a bug nonetheless, and any inference on my programming style based on this report is really the author's own concern...

---

I see what you mean, but which is the real bug in the code, the sequence structure not responding as you expect, or using the sequence structure in the first place... 

Mike...

[Darin.K]

We should all be so fortunate to have a user who systematically explores the deepest, darkest corner cases of our code and points out bugs along the way.  

If you write code in which every scenario is handled by its own special case, then it is easy to dismiss something like this.  (Plus I hope you get paid by the hour).  Instead if you try to write code more efficiently to handle a variety of scenarios then bugs like this can be quite significant.  Without finding the underlying cause, who is to say that it is limited to the SSS and won't come after a feature you use someday.

There are two distinct phases IMO.  Finding the cause of every bug should be a high priority, even ones as seemingly innocuous as this one.  Fixing the bugs can be prioritized and even put off indefinitely (I often prefer a major rewrite after many issues are discovered as opposed to dozens of band aids to try to fix specific problems while causing fewer new ones).

In short:  I think a CAR is certainly warranted, at least to determine if the bug lives inside code we care about or not.