H
ere are a couple of script examples you might find useful. Say you’ve got a multi-line text field or variable that contains a lot of text. To save time in scrolling (or clicking the ‘+’ icon next to the field) to see all of the text you just want to auto-expand the height of the field to fit its contents based on some other client-side trigger. Here are a couple of scripts that allow you to do that.
For standard form fields (and multi-line text variables in the service catalog)…
var fieldName = 'description';
var el = g_form.getControl(fieldName);
el.style.height = el.scrollHeight + 'px';
var el = g_form.getControl(fieldName);
el.style.height = el.scrollHeight + 'px';
For multi-line text variables on a standard form…
var varLabel = 'Special Requirements';
//Get the 'Variables' section
$('variable_map').up('table').select('label').each(function(elmt) {
//Find the label for the textarea variable
if(elmt.innerHTML == varLabel) {
//Find the textarea and change its height to match text
elmt.up('table').select('textarea').each(function(el) {
el.style.height = el.scrollHeight + 'px';
});
}
});
//Get the 'Variables' section
$('variable_map').up('table').select('label').each(function(elmt) {
//Find the label for the textarea variable
if(elmt.innerHTML == varLabel) {
//Find the textarea and change its height to match text
elmt.up('table').select('textarea').each(function(el) {
el.style.height = el.scrollHeight + 'px';
});
}
});
Hi Mark. I’ve used this technique in the past, and have an issue that the + and – buttons at the top right of the field stop working – have you come across this?
Brian
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.
el.rows = $A(el.value.split("\n")).length + 5;
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 🙂
Hello Mark,
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!
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.
Thanks for the quick reply Mark,
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’.
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.