LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
tst

LabVIEW should break VIs which have hidden code

Status: New

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):

 

AnnoyingVI.png

 

 

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?

___________________
Try to take over the world!
57 Comments
X.
Trusted Enthusiast
Trusted Enthusiast

Smiley Mad

fabric
Active Participant

Bold idea! I like bold ideas... but not this one 🙂

 

I'm with Jeff and Darin here. By all means, give us better feedback when hidden code exists, and provide better tools to un-hide it, but *please* don't force mandatory auto-tools on me where those tools have a combined IQ of about 42...

JÞB
Knight of NI
Make no mistake.... I showed the warnings for a reason. and in support if the side point that warnings are over generated. look closer. follow the dotted lines.

"Should be" isn't "Is" -Jay
tst
Knight of NI Knight of NI
Knight of NI

X., not cool. Some people might think it's real and thus avoid voting.

 

Fabric, I think you've been reading it incorrectly. The idea is precisely about giving better feedback about hidden code and NOT about mandatory auto-tools (or at least not tools which modify your code on their own). Darin was the one who suggested making AG mandatory.

 

Jeff & Darin, if you have a better solution for the issue, then by all means suggest it and let people vote for it. I would vote for an idea like the repelling nodes idea Darin made (which I'm guessing stems from Jeff K's demo at NIWeek). I might also vote for an idea which suggests a real improvement to the warnings list (I don't think the previous ones cut it and I think that hidden code should be treated as a syntax error anyway, so I don't think it would be a solution to this problem).


___________________
Try to take over the world!
fabric
Active Participant

"...The idea is precisely about giving better feedback about hidden code and NOT about mandatory auto-tools..."

 

Fair call... all that talk of auto-grow started making me nervous! Smiley Tongue

 

That said, I still can't agree with a change that will break runnable code. My positive suggestion is to colour the boundary of a structure red if it hides code:

 

hiddenCode.png

 

Intaris
Proven Zealot

I like Fabric's idea of shading the container which is guilty of harbouring spersecret code!

GuenterMueller
Active Participant
Me too: Fabric's proposal is great. Kudo for this.
SteenSchmidt
Trusted Enthusiast

@fabric: THAT is a great idea, to indicate on structure borders if they hide code - please post it as a new idea and I'll kudo it straight away.

 

It must be figured out how to handle that the structure could be colored something else but white, but some sort of indication would be great.

 

Please don't break the VI over hidden code, and please don't enforce auto grow (or else fix the fact that AG messes up the diagram when it explodes due to a coding unfortunity, usually when pasting code or doing string edits). I actually feel that auto grow won't work until the cleanup tool also works perfectly. And the cleanup tool won't work perfectly until it's not necessary anymore (since then the BD will auto adjust like Jeff demonstrated at NIWeek 2012).

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
tst
Knight of NI Knight of NI
Knight of NI

I don't think fabric's suggestion is practical, and here are a few arguments why:

 

  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?

 


___________________
Try to take over the world!
tst
Knight of NI Knight of NI
Knight of NI

@fabric wrote:

That said, I still can't agree with a change that will break runnable code...

 

hiddenCode.png



But that's exactly the point of the idea - we need to decide whether such code should be runnable. The fact that it is now doesn't mean it still needs to be.

 

The code you posted actually gives another excellent example of the principle - LV will break it because the loop has no indexing input, but you could argue that this is valid code and the loop should simply run 0 times. The decision to break the code in this case was done only to protect the user because 0-iteration loops are an extreme use case, just like hidden code.

 

My original point stands - if hidden code is not something we want to have, then LV should protect us from having it, at least passively.


___________________
Try to take over the world!