Shift-Enter should define word wrap bounds on Free Labels

[AristosQueue (NI)]

You might not know this, but if you drop a String constant on the block diagram (or create one from a terminal), you can use shift+enter to define the bounds as you type.

You start typing the first line. As you type, the constant gets larger. Hit shift+enter. Now as you continue typing, the string constant grows vertically only, using word wrap at the bounds of the string constant. Now hit shift+enter again. The string stops growing vertically and the vertical scrollbar appears on the constant. 

This behavior is very nice for creating string constants inside of structure nodes without having to create the item, then resize it, then come back and start typing your text. 

Wouldn't it be nice if the same shift+enter trick worked when typing free labels?  I think so.

[RavensFan]

I had a comment, but after rereading your idea, I have a better idea of what you are asking now.

I don't think the 2nd shift-enter turning on the vertical scrollbar would work for free labels or BD comments, but I do like your idea for locking in the right border for comments.

Message Edited by Ravens Fan on 03-12-2010 04:27 PM

[AristosQueue (NI)]

It puts in a carriage return, but it does not fix the width of the free label.

If I type "Abc def ghi" and then hit shift+enter, and then on the next line I type "jkl mno pqr stu", in the string constants, the stu will wrap to a new line AND there will not be a carriage return character in my string constant where I hit the shift+enter key originally.

And it definitely doesn't turn on a vertical scrollbar when you do it a second time. 

[tst]

I find this request so obviously needed, that I was sure it was already available as an idea (probably because we already discussed it in the past in another thread).

[jgcode]

Cool, I was looking to do this a while back myself with scripting, but had no luck.

http://decibel.ni.com/content/thread/5201

I would love to see this implemented. 

[RavensFan]

I looked at that thread you posted, and that got me doing some more experimenting with a block diagram label.

Leaving and reentering a label doesn't cause the label to have its right border become fixed.  If you had a new line and keep typing until it get longer than you current label width, the width will keep growing to accomodate without word wrapping.

If you leave the label then drag the border of the label to resize it, even if you wind up putting it back to its original size, then re-enter the label and type a new line that gets longer than the width, then the word wrap function happens just as Aristos Queue wants to see with the shift-enter.

So what changes in the properties of the label by the way of resizing it that causes it to go from growable to wrappable?  It looks like the the Size to Text property of the comment is set when you first create the comment, but when you resize the comment, the Size to Text property gets turned off.

Another interesting note is that if size to text is turned off and you add more lines, the older text scrolls out of the top of the comment box (okay, makes sense since you've now fixed the size of the box).  But that isn't necessarily a good idea, because the text is no longer visible, and you don't have a scrollbar to indicate there is more text vertically.

So to add to my earlier comments, I am wondering if a free label/comment should have the ability to have a scrollbar.  Part of me says no since you really shouldn't hide a part of a label or comment.  But once you fix the size of a box, LabVIEW as it exists now does let you hide part of a label or comment.  So shouldn't there be a vertical scrollbar to indicate that?

[AristosQueue (NI)]

> So shouldn't there be a vertical scrollbar to indicate that?

Yes. (In my opinion.)

[JÞB]

Good tip on strings!  And yes-free lables should do this too

[Ray.R]

Good idea & I learned something new 😉

[Jason_Harrigan]

Extremely important feature. Easy to implement, and it encourages well documented code.

[jtagg]

The fact that we now have the bookmark browser makes this even more important. If I create a free label the quickest way to wrap is to use carriage returns. Unless you resize the label afterwards it doesn't really matter. However, now that we have the bookmark manager, the carriage return actually creates a new line in something that should essentially be a single line and it becomes very obvious which labels were 'properly' created or not.