Visual indication that a structure is hiding code beyond its boundary

[fabric]

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code.  I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

• YES, I want better information when there is hidden code on my diagram, but...
• NO, I don't want my code to break!

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

 

[Intaris]

This idea is much preferable to breaking code because of hidden stuff.

It's like reminding you verbally to clean the dishes instead of hitting you over the head with an iron bar every time you forget.....

[fabric]

Yeah - the friendly reminder seems to be the preferred approach...

Still waiting for tst's kudo to come through. Surely the friendly reminder doesn't preclude the iron bar, if you're into that sort of thing!

[tst]

I'm not going to vote for this because my reservations still stand. I don't think the idea is bad, but I think it doesn't solve the real problem and would not be needed if a real solution was given. My suggestion, while being more extreme and having its own issues, is simpler, safer and more inclusive.

Shane's dish analogy, while cute, is flawed. If you want a more relevant one, you could think about a potentially unstable stack of dishes in the sink. Your suggestion puts a red note on top of the stack, but if the user covers the stack with a new dish, they won't see the note. My suggestion prevents the tap from being opened or soap being dispensed (i.e. doing actual work) before you fix all the stacks. Sure, if you don't fix the stacks, nothing might happen, but one of the stacks could fall over and break all your expensive china dishes.

[fabric]

Ok what about this:

You've got a sink full of soapy water and you're halfway through the washing up. (You're actually rather good at washing up and you do small dishwashing projects for people without kitchens.)

Anyway, you need to get some ice-cream bowls finished by the end of the day. In fact, someone has a penalty clause in their contract: They need to be able to use their ice-cream bowls tonight! 

The thing is, your new apple-scented detergent is so frothy that you can't see all the bowls in there! How will you know when the dishes are done?

Well, as luck would have it, your sink supplier has just released a ground-breaking new technology that locates foreign objects beneath the water line. And the best part about it is that your SSP is still valid, so you can install it right now... leaving you to get back to what you're best at: washing up.

[tst]

You see, that's the problem with analogies. Too often they stray too far away from what you're actually talking about and become silly and meaningless, so I would suggest we stick with LV. I never liked washing dishes anyway.

[Intaris]

Tst wrote:

Shane's dish analogy, while cute

That's all I want.  That's all I want.  I'm happy now. 

No seriously,  it's obvious where the analogies fail but I really DO NOT want to be reminded of a problem with something I'm currently not looking at.  What's the point in that?  That's a serious increase in noise.  That's regarding the problem being several layers down.  I don't want LV annoying me aobut things which might be located several layers below whaat I'm actually looking at.  I mean, what is the precedende for LV doing anything like that?  Up till now we deal with one layer of software at a time and I feel that's a huge benefit of LV over other languages that we really CAN concentrate on one level at a time.  But that's all subjective, the code still runs right?  The idea of breaking code for me is indiscutable.  I do not want it and I feel it's bordering on the silly.  At the very least it's OCD-like behaviour.

If you want a notice that there's hidden code in a layer below what's being shown, I could live with that I suppose but why on earth would you break the code?  What purpose does that serve?  What if the code due to LV auto-adapting from another LV version and the VI is locked with a password?  Unusable VI which is functionally A-OK?  No thanks.

[Intaris]

---

Tst wrote:

you could think about a potentially unstable stack of dishes in the sink. Your suggestion puts a red note on top of the stack, but if the user covers the stack with a new dish, they won't see the note. My suggestion prevents the tap from being opened or soap being dispensed (i.e. doing actual work) before you fix all the stacks. Sure, if you don't fix the stacks, nothing might happen, but one of the stacks could fall over and break all your expensive china dishes.

---

You need a better red note and not quarantine for the entire kitchen.

[tst]

Well, this all really belongs in the other thread and we did actually discuss it there, but to quickly rehash:

---

At the very least it's OCD-like behaviour.

---

Not at all. I want this not because I want the code to be clean, but mainly because I want to make sure there isn't an unknown piece of code somewhere. Hidden code is bad. Like I told AQ in the other thread, this would be like Visual Studio allowing you to color some of your code white so that now you can't see it.

---

I mean, what is the precedende for LV doing anything like that?...

...why on earth would you break the code?  What purpose does that serve?

---

Well, the precedent is any other syntax error which breaks the code and I would break the code because as far as I'm concerned hidden code shouldn't exist. Treating it as a syntax error rolls it into the regular mechanism we're all perfectly used to work with to fix broken code - click the broken run arrow and go fix it.

I don't have the answer for how it should handle every single thing, nor do I think it's an ideal solution, but I still think it's preferable to this one. Based purely on the number of votes, it would seem most people don't agree with me.

[SteenSchmidt]

A red plus sign might work as discussed in this idea:

Some indication that a structure is hiding code is particularly valuable for multi-frame structures like the case structure btw, as those lend themselves more easily to accidental code hiding when you resize based on what you see only in the currently visible frame.

And no, autogrow just isn't an option until it stops demolishing the BD (that'll be at the same time the cleanup tool starts working great, aka when Jeff's BD physics engine gets rolled out) .

/Steen

[fabric]

Steen: As I mentioned in your idea, I like the glyph, and I like the idea of consistency with hidden array elements and hidden string/path text.

That said, I'd almost certainly want the glyph to move according to where the hidden code lies. Your case structure image would be good for code hidden at the bottom-right, but I'd equally want to know if the code is at the far left by placing the glyph in th centre of the left edge of the structure.

Top edge glyphs may get messy, but I could live with that... After all, we generally intend to remove the hidden code once it has been found, right?

And for multiple chunks of hidden code, it would be sufficient to point me towards any one of them. (The biggest? The deepest hidden?)