Shrink-Wrap Structures

[DFGray]

Often, when modifying code, I need to reduce the size of a structure due to removing code.  If I have a nested structure system (e.g. event structure in a case statement in a loop), this can get very tedious.  It would be nice to have a "shrinkwrap structure" functionality on the right-click menu as a counterpoint to the autogrow.  This would be an action that would reduce the structure size to something a bit bigger than the largest contents.  An option to set how much extra space to include would be nice.

[JackDunaway]

I didn't even need to read the description to know what you were talking about and know I would use this feature. Kudos.

[Darin.K]

I am almost with you here, I am wondering why this behavior wouldn't be built in to the existing autogrow feature.  Expand when needed, give back space when possible.  Kind of like the 'Size to Contents' feature of a cluster. 

A padding parameter would be very useful, Kudos for that.

But, you still have to do something about moving the unwired iteration terminals.  They are pinned to the bottom-left corner at the moment.  When things start moving around it can start moving this to undesired places.  The ability to hide it is one distinct possibility....

[Mads]

A related idea can be found here.

[altenbach]

How is this different from selecting the outermost structure followed by the "cleanup" button?

(I know it's different, but most likely some rearrangements need to be done anyway. In a perfect world, both action would result in the same outcome).

[Intaris]

Altenbach,  the difference is that the structure should re-wize itself WITHOUT having to select it I think.....

[altenbach]

Ah, I see. I probably would have some problem with this. For example, I often create space inside a structure in order to add content, so I would not want to fight with an auto-shrink.

To prevent such fights, certain actions should not trigger a shrinking.

triggers: moving an item (or selection of items) with the cursors, etc.

non-triggers: placing an item, wiring items, resizing the structure, creating space with ctrl+drag, etc.

The resize operation should also go into the undo queue, so a single ctrl+z would undo the resize, but not undo the last user operation that triggered the resize.

I guess it would be similar in mechanism to the "size to fit" option of clusters, except that we want a little padding on the sides. "Size to fit" would probably be a better name for it and would include auto-grow and auto-shrink in a single menu item. The options could have a setting to decide if it should automatically grow, or shrink, or both, as well as the pad size in pixels (horizontal:vertical or even top:bottom:left:right ).

[tst]

I really don't think such an action should be done automatically. Auto-grow I like (or at least live with, despite its sometimes adverse effects) because if it's not active I run the chance of getting hidden code. This I wouldn't like because it would probably minimize structures even when I don't want it to (e.g. when I'm in the middle of moving stuff and putting things into the structure).

I think that such an operation is also sufficiently rare so that having a manual option is not a huge problem. The cleanup option doesn't work because it rearranges the code.

[JackDunaway]

Wait... the structure automatically resizes itself? I envisioned a right-click menu option that would "Shrink to Contents". I'm less receptive to an auto-shrinking structure that behaved like the 'Size to Fit' option for clusters, but I couldn't say for sure whether I'd like it without using it.

[DFGray]

To clarify, this idea is a manually triggered resize of the structure.  Items such as the internal "ears" of event structures and times loops would not overlap internal structures.  Unwired iteration terminals could be moved to an unobscured location (priorities for where could be set with options, as well).  I have been considering implementing a quick-drop or right-click framework version of this, but have not had the time (there are a few obvious non-trivial issues).  If I do, I will post it or link it here.

[tst]

Damien, this may save you some time. Initially, I tried using some of the obvious methods (such as the Auto Size method or another which is called something like Shrink to Content). None of them worked, obviously.

This shows two alternatives I was checking out (one in the T error case and one in the F error case). You can test them easily by using the test VI, which will launch it on the last active VI when you press the button.