I have noticed that the 'onkeypress="myfunc";' clause in my <textarea>
element is called properly with most all keys *except* the keys: Del, and
Backspace. I have not tested other special keys so far
I use the 'myfunc' function to warn the user of how many characters are
remaining before reaching my database limit.
I've tried this on Chrome and IE7 so far. Both react the same.
Does anyone have an explanation for this please ?
Thanks !
--
Mel Smith
I think there are some differences between keypress and keydown
Then more, order of onkeypress onkeydown click (and probably
onmouseover) is important
<http://unixpapa.com/js/key.html>
--
Stéphane Moriaux avec/with iMac-intel
>
> I think there are some differences between keypress and keydown
>
> Then more, order of onkeypress onkeydown click (and probably onmouseover)
> is important
>
> <http://unixpapa.com/js/key.html>
Stephane:
I tried using *onkeyup*, and it works perfectly (at least on IE7 -- I'll
try the others later) !
Thank you.
-Mel Smith
There certainly are. :)
What if he presses [ctrl || cmd]-v (paste) ?
--
Jorge.
Or shift+ins? I believe I covered that in my example (and monitor
onpaste where possible as well). But, as noted here a ways back, it
would be more robust to react to any keyup. Who knows what other key
combinations may change the text?
Et oui, bien sūr !
And not yet columns ...
Yes onkeyup + onblur would suffice I think.
> Who knows what other key
> combinations may change the text?
No idea, but it doesn't really matter, you don't need to know, you
just have to keep looking at whatever is left in the input.value after
every onkeyup/onblur event, istm. Or not ?
--
Jorge.
Thanks for the additional info re: onblur and the ctrl-key codes.
Now I've got something *more* to worry about.
My situation is that my <textarea> record fields in this particular
database are limited to 254 chars. I don't want the user to be pissed-off if
he creates the text, and then notices later that his text is cutoff in
mid-word, etc. So, As he nears the 254-limit, I change the the background of
the 'Characters Remaining' box to RED, and if he/she ignores *this* warning,
then I 'bleat' like hell for every additional character input, and then
reject the extra characters.
Thanks again !
-Mel Smith
> Who knows what other key combinations may change the text?
That’s a good question. I remember from a recent thread that there
appear to be people who think that most Apple keyboards miss a delete
key, and resort to arcane fn- combinations instead of good ole ctrl-d
(point in case for advanced interface stupidity: the WordPress WYSIWYG
editor inserts a DEL element with that combination).
Ctrl-a, ctrl-b, ctrl-d, ctrl-e, ctrl-f, ctrl-n, ctrl-p, ctrl-etc, on OS
X (unless it’s a Java app, or something worse) they almost always do
exactly what I would expect them to do. :-)
is that a question ?
<input
onkeyup="
var n=this.value.length;
this.style.borderColor = '';
if(n>254) {
// alert and focus are optional
alert('you reached maximum allowed characters');
this.focus();
// limiter of entering text
this.value = this.value.substr(0,254);
this.style.borderColor = 'red';
}
this.style.backgroundColor = n>=253? 'gold' :
n>250? 'yellow' :
n>245? 'lightyellow' : '';
document.getElementById('text_length').innerHTML = n;">
<span id="text_length"></span> characters (max = 254)
Sam:
No, its not a question -- I've already done it.
Thanks anyway.
-Mel
David:
Now, I've got to be on the 'look-out' for hostile or careless users who
'lean on' the <Enter> or <tab> keys and leave a massively empty <textarea>.
And before I allow the submit operation to take place, I must 'clean
house'.
I guess I have to delete leading and trailing useless chars (<cr><lf>,
<tab>, etc, etc) first.
I'll be puzzling on that tomorrow, and hopefully implementing it in JS.
btw, After the <textarea> is submitted, and placed in my database, the
text is later called up and displayed in a <td>lots of text up to 254
chars</td> element.
Thanks.
-Mel
The blur event would be another time to check (in case the value was
changed in some way that could not be accounted for by monitoring the
keyboard).
It should be noted that these sort of activities are strictly for
saving the user time. Ultimately, the server side script must enforce
validation rules as JS can be disabled (or scripts modified) on the
user end.
I do remember having to get used to some differences with the last Mac
(a laptop) I used (which was the first in a very long time). ISTM
that the delete key was backspace and Ctrl+D was delete.
That reminds me that my character counter demo does not watch for that
one. Best to react to all keyup events, except when trying to
demonstrate the capabilities of a keyboard monitoring script. Of
course, I'm sure some people have tried to use Ctrl+D, noticed that
the counter didn't update and assumed that the listening script
(rather than the demo) is broken.
> and resort to arcane fn- combinations instead of good ole ctrl-d
> (point in case for advanced interface stupidity: the WordPress WYSIWYG
> editor inserts a DEL element with that combination).
You mean they use Ctrl+D as a shortcut in their editor? Ctrl+[A-Z]
should be considered off limits for such things. But I guess they
looked at the accelerators for whatever browsers they had handy and
noticed it wasn't taken. If only they had tried pressing that
combination in their editor instead. :)
They were last spotted going South on Main.
>
> And before I allow the submit operation to take place, I must 'clean
> house'.
Or stop the submit in the event of invalid data. Same difference as
both can be circumvented by those truly hostile users who insist on
disabling JS. :)
>
> I guess I have to delete leading and trailing useless chars (<cr><lf>,
> <tab>, etc, etc) first.
But don't trim while they are typing. Personally, I wouldn't trim the
input value at all (but would trim the string that I validate, both on
the client and server side).
>
> I'll be puzzling on that tomorrow, and hopefully implementing it in JS.
On the client and server side I hope.
>
> btw, After the <textarea> is submitted, and placed in my database, the
> text is later called up and displayed in a <td>lots of text up to 254
> chars</td> element.
>
Okay.
Thanks (I think).
> And not yet columns ...
I know. Been too busy to mess with the layout of that demo. I'll get
to it eventually.