LabVIEW should break VIs which have hidden code

[tst]

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

I think LV should break any VI which has any of the following:

• Objects beyond the visible boundaries of structures (including wires and constants).
• Objects behind other objects (possibly not including wires).
• Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
• Anything else?

[Intaris]

Tst Wrote:

1. Do you also do that if the structure hides code behind it (this is demonstrated in the original snippet, as Jeff's image shows)?
2. What do you do if what hides the code is not a structure, but a VI or a node?
3. What happens if the hidden code is in a VI which is three layers of subVIs down?
4. What happens if the hidden code is in another frame of the structure?
5. What do you do if the structure or diagram has different colors?

Answers:

1. Yes, either by colouring ALL 4 Borders (Borders could also be coloured along not the entire edge if neccessary, thus heling locate the offending code) as required or alrernatively having the borders colour internally or expernally depending on where the offending code is.
   
2. A VI or a Node are not the topic of discussion here.  We're discussing Structures.
3. I don't understand this point at all.  Only the VI can be hidden, it's contents are unimportant.  Maybe I don't understand you.
4. Makes no difference.  Perhaps double-clicking the coloured portion takes you there.
5. Explode the computer because this is clearly not possible.  Nah, seriously, how about simply inverting the colours being shown with perhaps an exception for tricky grey cases.

[fabric]

I'll take my opportunity to respond too. And for the record, I definitely agree that warnings for hidden code are a good idea.

1. Do you also do that if the structure hides code behind it (this is demonstrated in the original snippet, as Jeff's image shows)?

No.  Don't colour the structure if the hidden code is not contained within the structure. (A possible approach for code hidden underneath the structure would be to superimpose a red outline above the hidden code - where the marching ants are shown in Jeff's image.)

2. What do you do if what hides the code is not a structure, but a VI or a node?

Probably nothing.  At most I'd overlay something along the lines of the red "X" used to identify bad wires.

3. What happens if the hidden code is in a VI which is three layers of subVIs down?

Nothing.  I cannot see normal code in a sub VI three layers down. Why should I be able to see hidden code? (If you want to go to your hidden code then just double-click the warning message.)

4. What happens if the hidden code is in another frame of the structure?

Nothing.  I can't see normal code from case 1 when I am viewing case 3. Why should I see hidden code?

5. What do you do if the structure or diagram has different colors?

We're programmers, not designers!  They pay someone else for that 

Anyway, you don't normally use RED, do you?

[tst]

---

A VI or a Node are not the topic of discussion here.  We're discussing Structures.

---

Maybe you are, but this is my idea and I'm discussing hidden code. I don't care what hides it. I just want it to not be allowed (and in case you're wondering, I have run into the someone-accidentally-duplicating-a-subVI-in-place-and-then-not-understanding-why-their-code-doesn't-work situation before).

---

I don't understand this point at all.  Only the VI can be hidden, it's contents are unimportant.  Maybe I don't understand you.

---

My request is simple, and this should also answer fabric's question - I don't want to have any hidden code anywhere in the hierarchy. I don't care if I am looking at the VI which has the hidden code or if I'm looking at another VI. I just want LV to tell me that there is hidden code somewhere so that I can go and unhide it. Breaking the VI allows us to see it immediately and doesn't require adding all kinds of overlays to the BD which require handling different objects in different ways.

[X.]

My bad for having triggered tst's post, which comes in part in (over)reaction to this thread (but he has been vocal about it in many others).

I would agree that there are horripilating cases of hidden objects, like loop terminals, for instance. And unless you would want to slide a piece of deprecated code under the carpet, so to speak, the practical use of hidden code appears limited. Should people be prevented from hiding code? I let the people vote on that. Mine has already been cast above.

I'd suggest have a kind of LED indicator somewhere at the top of the BD window showing that here are hidden objects in the diagram (and giving quick access to the corresponding list in the warning window). This could be generalized to other useful diagram metrics/info (list of terminals, functions, VIs, etc).

PS: I wonder whether the list moderators will have a sense of humor...

[Intaris]

---

Maybe you are, but this is my idea and I'm discussing hidden code.

---

Oops, indeed.  I got carried away.  My humblest apologies.

[Intaris]

Doesn't VI Analyser already show up instances of hidden code?

[SteveChandler]

tst, you are right about X's comment. I almost didn't vote because I initially thought it was real. I first read it on my phone so it didn't stand out so much. Being the last post on the first page might cost some votes. I think the moderators should edit that.

[tst]

> Doesn't VI Analyser already show up instances of hidden code?

It does, and so does the warning list (to some degree). I mentioned both in the idea and I don't think they're enough.

[johnsold]

I think the amount of discussion generated by this idea shows that a real issue exists with hidden code.  It also shows that consensus has not yet developed on what to do about it.

- The VI Analyzer is not available to everyone, so is not the only or best solution.

- Breaking code seems a bit harsh, particularly since doing so would be a radical departure from past practice.

- The suggestions about colored borders, better warnings, and markers on the BD that code may be hidden all have merit as well as drawbacks.

- Anything chosen should be somewhat customizable via the options (preferences) panels since a diversity of strong opinions is present.

Let's continue the discussion.  New ideas or refinement of those already proposed may lead to a consensus.

[rgvdh@rdf]

I think the fundamental problem here is the crudeness of the "warnings" system. If you could say something like "show me warnings for hidden code, but don't show me all those useless warnings for 'unlabeled terminal in event structure'" then those who want to hunt down and kill all hidden code could be accommodated without inconveniencing those who need to hide an ugly kluge from their boss ;-).