LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Darin.K

Structures should not be allowed to hide code in diagrams!

Status: New

The crux of this idea is a very simple premise:  Structures should not be allowed to hide code inside their diagrams.  Ever.  Period.  There is no legitimate reason.

 

The rest is implementation details which are negotiable, unlike the basic premise.

 

With Autogrow enabled this is not an issue.  So it could be as simple as removing the option to turn it off.  I would prefer a slight alternative, allow autogrow to determine two different behaviors when an object pushes against a structure boundary:  Autogrow = object wins and structure grows.  No Autogrow = structure wins and object no longer moves.  All structure growth is done by hand in that case.

 

NewAutogrow.png

 

When upgrading VIs which have hidden code, I suggest a one-time autogrow.  Breaking code could be an option ( Smiley Wink ), but that would simply force the user to autogrow or cleanup the BD anyway.    If there are other errors, a broken run arrow is not a clear, direct indication anyway.

 

There could be a corollary preventing hidden code in general.  I may not agree with them, but I do see that there could be an argument there to allow hidden code in some cases.  That battle is being waged elsewhere:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-should-break-VIs-which-have-hidden-code/idi-p/...

 

I see no reason, however, to allow the bounds of a structure diagram to shrink beyond the bounds of its content.  Nefarious reasons? yes  Legitimate ones?  not that I can think of.

 

I empathize and support this idea as a start:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-a-structure-is-hiding-code-beyo...

 

But I do not want a visual indication, I want to know by construction that nothing lies beneath.

24 Comments
stbe
Active Participant

@Darin.K thanks for this Idea request - I'm fully in with you (and because of the quite heated discussion I'm going to support your arguments 😉 )

 

I usually debug "small" VIs where there is enough place to put the code (and if I have to stretch 5 structures to fiddle in the debug code, there's something wrong with that (there should be subVIs! - you know, with inlining perfomance is also maintained). In such cases, I rather prefer larger overall VIs (even if you need to scroll in one or the other direction, but NEVER hide something)

 

This is also the reason that I enable the autogrow structures flag -> because I do NOT want items to be hidden anywhere (and it's also some kind of guideline within my SW development team)

 

Another possibility (that would be sufficient for me) is that LabVIEW (if autogrow has been enabled) resizes any structures where elements are hidden when such a VI is opened. I know that this could get messy (but I usually know who saved/modified the VI before me - so I can talk to her/him) and - afaik - enabling autogrow for structures does currently not apply to already saved VIs.

_________________________
CLA
SteenSchmidt
Trusted Enthusiast

No, enabling autogrow as default does fortunately not affect already purified structures 😉 In my opinion autogrow can be safely enabled the day the cleanup tool makes sane block diagrams, because then that could be run automatically just after an autogrow event.

 

Btw. inlining does not work for debugging - you cannot debug inside an inlined subVI. Inlining is not equal in performance to code dropped straight in either. Close, but not equal. The latter is just for reference as it's a moot point when debugging with probes for instance.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
X.
Trusted Enthusiast
Trusted Enthusiast

NI is already overriding the "Autogrow OFF" flag in structure sub diagram labels.So I guess, as the saying goes, when the bounds are crossed, there is no limits....

fabric
Active Participant

@X. wrote:

NI is already overriding the "Autogrow OFF" flag ...


Likewise for most scripted VIs and VIs created from templates (e.g. class accessors and overrides)...

 

I'm sure it was technically easier for NI to "pick one way and go with that", but I feel a bit ripped off about having an option to disable auto-grow that is becoming increasingly half-baked (=quarter-baked?!) as new functionality is added to LV. 

 

All this kind of banter pulls us in the direction of a global auto-grow setting, but that's probably another idea.