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
crossrulz
Knight of NI

I have been bit way too many times by the overlapping tunnels!  Definately need this.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
JÞB
Knight of NI

That is exactly why there are VI Analizer tests for each of those conditions! why ship software (or even accept a peer review request) without the VIA report?


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

>...why ship software (or even accept a peer review request) without the VIA report?

 

  1. Not everyone has VIA.
  2. If it's something which should really not be done (and I think hidden code qualifies), it should be part of the editing experience. I don't want it to be optional or after the fact.

___________________
Try to take over the world!
JÞB
Knight of NI

The Warnings are enough for me.  no reason to break code that is compilable

1!.PNG

1a.png1b.PNG


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

The problem with the warning dialog is that it shows quite a lot of warnings which are not very useful (such as the unwired terminal warning) and the useful warnings are lost in the noise.

 

As for "not breaking code which is compilable", that's basically a tautology - deciding what breaks the VI is exactly deciding what is compilable (e.g. NI could decide that the bottom input of the Add primitive should be made optional, thus making code which doesn't use it compilable). My position is that hidden code should not exist, but because that's an issue, the alternate suggestion is to break it. Are you suggesting that it should be allowed? Is there any situation where you find hidden code desirable?


___________________
Try to take over the world!
JÞB
Knight of NI

"Are you suggesting that it should be allowed? Is there any situation where you find hidden code desirable?"

---------------------------------------------

Yes, it should be allowed (and currently is)  do I find it desireable? NO! I go out of my way to enable the warnings since this is not the default for the IDE.  I do think that some customization is possible by digging into the guts of LabVIEW to remove some warnings you do not care about.

 

What you seem to be suggesting is a change elevating this specific warning to an error.  I can't support changing the current behavior or imagine the compatability nightmare it would cause by breaking existing running code. 


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

That's what Diagram Cleanup is for...Smiley LOL


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Darin.K
Trusted Enthusiast

My own view is that too many things already break code in LV.  (For example I think unwired "required" inputs should only be a warning).  This seems way over the line I already think is misplaced.

 

A developer creates hidden code:  fix the developer.

Warnings arent' sufficient:  fix the problems with warnings.

Autogrow isn't sufficient:  fix the problems with autogrow

Block Diagram cleanup won't help:  fix the problems with the cleanup tool.

 

IMO the solution to this is to fix autogrow and make it mandatory.  The bigger picture is to improve the layout and drawing tools.  Nodes should be "rigid" IMO and push around other nodes and structure boundaries so that nothing overlaps or is hidden.

elset191
Active Participant

@tst wrote:
The problem with the warning dialog is that it shows quite a lot of warnings which are not very useful (such as the unwired terminal warning) and the useful warnings are lost in the noise

Agreed. See also.  And a few comments here.

--
Tim Elsey
Certified LabVIEW Architect
SteveChandler
Trusted Enthusiast

That was kind of messed up (and somewhat humorous) X. It at least needed a smiley Smiley Very Happy

=====================
LabVIEW 2012