Great idea. Forget about putting that checkbox for multi-lines. Just automatically adjust the height. That way you're minimizing the form's size in the beginning and adjusting as needed.

Automation is the godliness of computer software. If you save the user time, the user will love you.

I think that this would be wonderful, with one warning though: you'd have to check to make sure that UI that you designed with this "looked okay" and could handle both the one line and expanded boxes.

Just boundary checking which I know you'd do in spades. ;-)

There's a couple things you might want to think about. What constitutes one line? Depending on text size, one line might not be much at all. Some people have their text set quite large, because they have trouble seeing. Maybe selecting a length for the fields, and then building a form to suit the input would be a better idea. Specifying the type of data that's going to go somewhere will make things a lot easier in the end.

Here's a link I stumbled across that might be of interest. Basically the rule states that if you are going to allow some value of N > 1, then you might as well add for infinity, or as much as the memory can handle. Creating arbitrary limits just causes problems.

http://c2.com/cgi/wiki?ZeroOneInfinityRule

It's been a long holiday -- how does this relate to an expanding text box?

I think it goes like this. How do you make your UI cope with the expanding textbox. Depending on the text size, font used, and probably a billion other things, how will you adjust your entire UI to compensate for the new space taken up by the widget. Anyway, basically what i'm trying to say, is that it's probably better, and a lot easier from a design perspective to go with a one-line,N-Line input rather than a one-line, two-line, three-line, four-line, N-line. Something, (eg. Copyright date) are only every going to need one line. Other things, are going to need N lines, it's either 1, or N.

The view that contains the expanding text box widget could expand vertically and scroll if the form becomes long.

The inside of the text boxes also scroll when they get past 4 lines -- the text box will only display 4 lines at a time maximum.

When it comes to software there's a certain amount of planning you can do to get corner cases, but corner cases sometimes make a simple thing a very complicated thing. Complicated things take more time to maintain, which is bad.

I may have to plan for large fonts but until enough people complain about it I probably won't worry about it. I have to set priorities or else the software will stop doing new useful things -- it will just be perfect looking for every combination of monitor, video card, resolution, colours and it just goes on and on. Perfection like that doesn't seem worth it.

The real problem i forsee, and what I've seen in many applications, is that expanding the UI height can have bad effects is that if the UI is expanded too high, it might go off the bottom edge of the screen. Unless the UI will account for this, and have the UI scroll much like webpages do, then you will probably run into problems. You do not know how many Linux applications I have seen where you can't reach stuff in the UI unless you have 1024x768 resolution. Anyway, I think there might be a better way to create the widget. Maybe a button beside a text box that opens a small windows that lets you entere longer strings.

That's a lot of mights for something minor. Let's just see when we get there, my good man. YAGNI!

Cheers!