This solution only takes actual line breaks into consideration. Text input with multiple lines and no line break will therefore be not taken into account.

To avoid that you could use the following:

var el = g_form.getControl(‘description’);
el.rows = Math.round(el.scrollHeight/15);

You can still use the + and – buttons by the way.
It’s pretty much 15 px per line, so it will show you all lines with and without line breaks. It’s not elegant, but it works :-)

The only thing you should have to change is the ‘varLabel’ line at the top. It should be the actual label, not the name. I wonder if there might be an issue with the forward slash. You might try without it. If you can set up the issue and reproduce it in the ServiceNow demo instance I can try to debug there.

I should have mentioned my browser in my initial comment. Sorry about that.
I’m using IE 8, and since I have Firefox installed too, I tested with it ( FIrefox 3.6.13 )
I don’t have Chrome, but this puts me in a dilemma, my users use IE, so if I can’t get something to work with IE, I probably will have to point everyone to the “Printer Friendly View”.

In any case, I am still interested and I did test with both broswers. Which leaves me with another question concerning the first line of the script.
Should the value in quotes be the name of the cataloging variable? Or the question? My situation is this, the variable is named “purpose” but the question is “Overall Purpose/Big Picture”.

I did try both names without success, but i have to wonder if your use of label in the variable “varLabel” and the use of ‘label’ in the select statement are related. I’m thinking that perhaps I should change that to ‘name’.

Your first line is correct. Can you test in Firefox or Chrome and see if it works better? I think this might be an issue with a Prototype bug in IE.

I’m trying the second case in your script. I have a requested item, with a cataloging variable named “purpose” which can get wordy.
I inserted a client script for Requested Items with the 2nd flavor of your script to no effect.

I then thought that maybe I need to tailor it to my form. So I changed the line reading
$(‘variable_map’).up(‘table’).select(‘label’).each(function(elmt) {
to read like this
$(‘variable_map’).up(‘table’).select(‘purpose’).each(function(elmt) {

Still no dice… :-(

I’m hoping that I’m missing something which is obvious to you and that you can reveal where my ignorance lies.

Thanks in advance!

That’s a good point. The way around this is to adjust the ‘rows’ attribute of the textarea. Unfortunately, I know of no simple, cross-browser solution that can calculate the number of rows that way due to a variety of factors including font size and continuous lines.

You can approximate the correct number of rows by counting the number of line breaks in a text field though and then try to pad it a bit to account for continuous lines. Here’s a sample script that will do something like that. Just be aware that there may be some cases with this script where the contents won’t be completely displayed. If anyone has a script that can handle this issue I’d be happy to post it.

var el = g_form.getControl('description');
el.rows = $A(el.value.split("\n")).length + 5;

Brian