Visual help in fixing broken local variable linkage

[Intaris]

I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.

I get greeted by the hugely informative imagery as shown below:

Yeah, good luck realising what exactly you deleted by mistake.  No name, no way of finding out what the local PREVIOUSLY linked to.

I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error.  Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.

An example of how this could look:

Here I at least know WHAT I have deleted by mistake.

[Intaris]

I also thought the idea should apply to references and PNs also, but I didn't want to have to so many graphics.....

[altenbach]

My suggestion would be to retain the all-black color with white background of the current behavior, but simply leave the old name in place. There should be no question mark on it, just the old name.

Black is the corrrect color for broken stuff!

Retaining the color seems too ambiguous to be of much help (e..g. we could not tell the difference between a I32, enum, tab control, or radiobutton, for example. The are all the same blue!) Once the control is gone, there is no more "type" associated.

[JackDunaway]

This can be generalized to include Property Nodes and References (agree with fabric -- "my kudos is conditional on it applying to references and property/invoke nodes as well... and possibly orphaned event cases")

One real-world example is when you have PNs and/or Refs to a Pane, the you add or remove a splitter.

Neat idea Shane, +1.

[A-T-R]

Very good idea! Really! Excellent!

I hate when I have to use the "undo" option several times, "just" because I can't remember which control I deleted, and then lose the the work I have done since this "mistake"...

[Manzolli]

Liked the last option: color text, grey bacground, black border.

[gsussman]

This idea could also be tied to this one: Always break Unbundle or Bundle by Name when the item in the cluster is removed

Kudos

[PaulG.]

And another thing ... why would you want a local to a control that doesn't exist? This is a bad idea.

[dthor]

---

@PaulG. wrote:

And another thing ... why would you want a local to a control that doesn't exist? This is a bad idea.

---

Obviously a black local would be invalid and throw an error if you tried to run the broken code.

When refactoring code, I'll go through and delete groups of controls/indicators at a time, because I'll be connecting things with wires later. Imagine you delete 3 controls at once and they all have locals. You knew the locals existed, as you did a search for them earlier. All the locals are on the same page of the state machine. Now that you deleted the controls, which local went to which control?

In fact, here are some images showing what I mean:

We start off with 3 controls or indicators, with locals used elsewhere. Pretent that the 2nd frame is hidden away in a case structure or something.

Then we delete the indicators because we don't need them, and want to just connect wires up. Oh shoot! Which local was which?

Well this is the way that makes the most sense, so I'll just connect it up.

And then we wonder why there's a bug in the program. The resulting code is not the same!

If the names of the locals (or reference or property node or whatever) were kept, then it would have been much easier to connect the wires up in the right order.

I think that this is a great idea.

[X.]

Sort of reminds me of the "Let's scramble the order of Controls in the connector pane" feature upon creating a subVI from a bunch of selected objects.

I have concluded that this is a deliberate NI trick to discourage complacency and reliance to LabVIEW's intelligence.

The same probably applies here. It probably just tells you not to overuse local variables... Sort of a punishment if you will.

JK.

[tst]

> Sort of reminds me of the "Let's scramble the order of Controls in the connector pane" feature upon creating a subVI from a bunch of selected objects.

I didn't do a thorough study (I don't create subVIs from code that often), but it seems to me that since NI added the extra smarts to it in 2011 it has been behaving much better.