Resize / Move Free Label While Typing

[Wee-Bey]

It would be nice to be able to resize or move a free label while editing it. This idea revolves around a couple of situations that can occur when typing up long free labels.

Situation 1

If I type up a long free label inside of a structure, then I can't resize or move the free label while I'm typing in it. If it becomes too long and extends outside of the structure I'm typing in (loop, event, or case structure), then it automatically expands the structure no matter what I do next.

As soon as I click out of this free label or try to resize it, it will resize the While loop. Usually, this isn't my intention. I usually want to shorten the width and increase the height (to make it multiple lines), or move it somewhere else. Currently I have to finish typing, resize or move the free label, and then manually resize the structure to its previous size. If instead I can resize or move the free label as I type, then I don't have to manually resize the structure to its original size; I can just fit the free label where I need to in the first place.

This same behavior occurs if I try to move the free label while typing in it; the structure resizes, even though I'm moving the label outside of it or somewhere else.

Then as soon as I finish typing...

Situation 2

If I type up a long free label and the single line runs to the right of the block diagram, then I can't see what I am typing.

At this point, it would be nice to resize or move the free label. Instead, I have to resize my block diagram window, or click out of typing, move the free label, and double-click to continue typing.

Thanks for listening!

[fabric]

Situation 1:

Turn off Auto Grow. Works for me! 

Ideally we could get something like this so that expansion of structures is an efficient operation based on a premeditated decision... rather than a heavy-handed default setting with a one-size-fits-all implementation! 

... but I guess some people like it the way it is, right?!

[tst]

String constants allow you to click Shift+Enter to cap the horizontal size while typing. Comments don't allow the same, but there is already an idea saying that they should.

I suggest simply voting for that idea, as it solves the same problem using an existing mechanism -

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Shift-Enter-should-define-word-wrap-bounds-on-Free-Lab...

[SteenSchmidt]

I'm with fabric here; just turn of auto grow like everybody else (or is it just us?), then you're good. I don't want temporary stuff to mess up my diagram.

Cheers,

Steen

[Wee-Bey]

SteenSchmidt and fabric, turning off Auto Grow would solve Situation 1, but I'm one of the odd ones who finds auto grow useful in other situations. 🙂

tst, as for shift+enter, it caps the horizontal size for one line, and then it actually affects the formatting of the text as well (places a carriage return where you break it), which is something you like to avoid, especially if you want to resize that free label later on. The beauty of resizing a free label with the mouse (which you currently can do after typing it up) is that it does not affect the text formatting at all with carriage returns. I can copy and paste that text into another text editor (or my VI documentation, as is often the case for me), and it treats it like one line instead of something broken up where there was a line break.

Thanks for the feedback, y'all!

[tst]

> as for shift+enter, it caps the horizontal size for one line, and then it actually affects the formatting of the text as well (places a carriage return where you break it)

I just checked and Shift+Enter on a string constant does not add a line break. It caps the horizontal width the first time and then it seems to toggle the scroll bar visibility on subsequent uses, which seems to control whether the constant will grow vertically as you add text.

For what it's worth, I also use auto-grow and I think the majority of LV users use it, if only because it's the default and they don't know to disable it. In any case, I don't think suggesting turning off auto-grow is practical since using or not using it is a matter of personal preference. Personally, I would actually advocate getting rid of the ability to disable auto-grow, because it allows users to hide code and I prefer safety, but I know there are those who wouldn't be happy with that.

[Wee-Bey]

tst, I apologize; I misread your comment. I tried it with the free label, and I think I was just seeing the behavior of hitting "Enter". So yeah you're right, implementing for a free label what happens with a string constant would be one way to solve the problem. However, being able to move it or reshape it would add more flexibility and be more UI-friendly, at least for me. 🙂