LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

Allow Choosing the Scope of the Expand/Shrink Diagram Tool

Status: New

The updated diagram expansion  (Ctrl+Drag) and its new counterpart (Ctrl+Alt+Drag) is a definite improvement in 2015.

However, they still both act globally on the diagram:

 

Screen Shot 2016-06-28 at 14.19.02.png

 

Shrink and obtain this:

 

Screen Shot 2016-06-28 at 14.19.12.png

 

All the objects outside of the case structure have been moved around because the shrinking action acted on the whole diagram, whereas my intent was to only compactify things inside the structure.

It would seem that the next step to improve the functionality of these tools is to allow the user to define their scope:

- define a region of interest meaning: DO NOT CHANGE ANYTHING OUTSIDE THIS ROI

- perform the action (expansion or shrinking)

 

In this particular case, this would work like this:

 

Screen Shot 2016-06-28 at 14.23.33.png

Screen Shot 2016-06-28 at 14.24.12.png

 

There is still some cleanup to do, but this is much less of a pain that fixing the carpet bomb effect of the current approach.

Arguably, this is easier to grasp with the "shrink" tool, but just think of the exact inverse series of steps to get an idea of the difference between the image at the top and this (the result of the current expand):

 

Screen Shot 2016-06-28 at 14.28.42.png

7 Comments
Mythilt
Member
Perhaps set it so that if there are items selected, the grow/shrink action only works on those items, rather than globally. Would probably be more intuitive and easier than adding a step to define a region.
Jon D
Certified LabVIEW Developer.
X.
Trusted Enthusiast
Trusted Enthusiast

That sounds like a good idea, although at this time, you lose the selection when Ctrl-left-clicking on the diagram.

Note however that in the suggestion, the definition of a ROI is needed when there is nothing to select (in order to precisely define the ROI). Now, of course, this could be solved by a "trick", i.e. impose that a ROI will be either:

- defined by the bounding box of a set of selected objects (as you suggest)

- defined by the structure the Ctrl-(Alt)-click happens in

 

Although the latter sounds limiting, it is what we are using the Sequence Structure for a lot of things already (e.g. create a dummy subVI which will later on become one).

 

Which brings me to one important suggestion which I did not include in the original proposal, but which I had wished existed so many times and definitely belongs it:

 

Allow the scope of an expand/shrink action to be limited to the visible case of a structure.

 

In other words, push things around (or compactify them) within one case without messing up with the diagram in the other ones.

Priceless!

elset191
Active Participant

@X. wrote:

 

Allow the scope of an expand/shrink action to be limited to the visible case of a structure


I can definitely get down with that suggestion

--
Tim Elsey
Certified LabVIEW Architect
Nils_Thomsen
Member

The RoI Solution probably isn't pretty handsome and will lead to a lot of confusion.

 

There might be two different solutions for this issue:

 

1) Limit the growth and shrink to a selected area or to the whole document if none is selected

2) When pressed Ctrl/Alt/Shift the groth / shrink will be limited to only inside of the container, where the mouse is within.

X.
Trusted Enthusiast
Trusted Enthusiast

Might not be handsome, but it does things that the other options don't (see my illustration above, where there is a region with nothing in it). However, as I also said, I would be fine to have to resort to dropping a temporary sequence structure (or any other structure) to define a ROI to which the action would be limited.

 

Obviously, this scope limitation has some potential problems. For instance, what do you do in this situation:

Screen Shot 2016-07-01 at 09.53.30.png

 

The simplest solution is to do this (assuming expansion is towards the right hand side):

 

Screen Shot 2016-07-01 at 09.53.55.png

 

But that isn't too good (risk of hiding lots of stuff inadvertently).

Another option would be to do this:

 

Screen Shot 2016-07-01 at 09.55.49.png

Screen Shot 2016-07-01 at 09.56.43.png

 

This is asking for a level of an additional level of sophistication from the tool, but the added value in terms of help to programming would be invaluable.

Nils_Thomsen
Member

Uff hell no! 🙂

 

The tool should NEVER EVER! start to shrink or grow in another direction than the expected. That would be horrilbe because it'd start do compress parts of the program never expected to. You would need to do mental programming 5 steps in your head always regarding the possibility to come to the need to resize.

 

I don't think that this is a great idea.

 

If there's no more space, and the growth is limited to an RoI, then there's simply no possibility to grow.

X.
Trusted Enthusiast
Trusted Enthusiast
With the new real-time visual rendering, this is less of a problem, but I agree that it is departing from the current behavior. If you don't break habits, nothing new will ever come out of it...