By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,668 Members | 1,481 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,668 IT Pros & Developers. It's quick & easy.

focus() won't work when function called with onblur

P: n/a
Tearing hair out time! Simple attached page shows the problem.
http://www.brilley.co.uk/TestFocusSelect.htm

Using a function to test if too many characters have been keyed in to a
textarea. Obviously, must return focus and select to the textarea if too
many have been keyed.

When the function is called with onblur, it works in IE but not in Safari or
NN. The function is called but the focus() and select() methods fail.

Something stupid I'm doing, I'll be bound.

Thanking you in anticipation.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Jul 23 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Roger Withnell wrote:
[snip]
When the function is called with onblur, it works in IE but not in Safari or
NN. The function is called but the focus() and select() methods fail.

Something stupid I'm doing, I'll be bound.

[snip]

First, I *hate* things that trap me - with your form, the
user can't escape until they meet your criterion for the
textarea and enter zero to three characters. The event will
keep firing every time the box goes in and out of focus, so
if I change to another application, your alert keeps poping
up when I return to the browser.

So, please think carefully if there is some other (kinder)
way to do what you want.

The following is in regard to Firefox, but I suspect the
same is true for NN and Safari...

If you use an external button to run your script, it works
as expected - the alert pops up and when dismissed, the text
in the text area is selected. Incidentally, there is no
need to call focus(), select() will set focus on the
selected text (same for IE 6).

However, when run using onblur, closing the alert does not
seem to return focus to the textarea. When I subsequently
click on the textarea, it is selected for a moment, then a
cursor is placed in the text roughly where I clicked.

This indicates that the textarea content is not selected
until I put focus back on the textarea - but now it must
deal with the click, so it un-selects the text and puts
focus where the click occured. Perhaps execution of the
select is stopped until focus is returned to the textbox?

If I change to another application, then return to Firefox,
the text is selected. So it seems the "onblur" does not
really finish until the document or window loses focus.
Also, if I put focus on the textarea then change
applications, the onblur fires twice so I have to deal with
two alerts.

I tried a few work arounds, they were all messy and very
unsatisfactory. I'd just avoid this altogether and validate
the textarea on some other event.

Rob.
Jul 23 '05 #2

P: n/a
Rob

Thanks for your thorough and extensive analysis.

My problem is that the form is putting the text into a database table field
which has a finite size. So I must stop the user entering more characters
that the database table wants. I don't want to discard the text that is
over the limit. I want to give the user the choice to adjust his text
within the limit set by the database table.

How do you suggest I achieve this?

"RobG" <rg***@iinet.net.auau> wrote in message
news:GG*****************@news.optus.net.au...
Roger Withnell wrote:
[snip]
When the function is called with onblur, it works in IE but not in Safari
or NN. The function is called but the focus() and select() methods fail.

Something stupid I'm doing, I'll be bound.

[snip]

First, I *hate* things that trap me - with your form, the user can't
escape until they meet your criterion for the textarea and enter zero to
three characters. The event will keep firing every time the box goes in
and out of focus, so if I change to another application, your alert keeps
poping up when I return to the browser.

So, please think carefully if there is some other (kinder) way to do what
you want.

The following is in regard to Firefox, but I suspect the same is true for
NN and Safari...

If you use an external button to run your script, it works as expected -
the alert pops up and when dismissed, the text in the text area is
selected. Incidentally, there is no need to call focus(), select() will
set focus on the selected text (same for IE 6).

However, when run using onblur, closing the alert does not seem to return
focus to the textarea. When I subsequently click on the textarea, it is
selected for a moment, then a cursor is placed in the text roughly where I
clicked.

This indicates that the textarea content is not selected until I put focus
back on the textarea - but now it must deal with the click, so it
un-selects the text and puts focus where the click occured. Perhaps
execution of the select is stopped until focus is returned to the textbox?

If I change to another application, then return to Firefox, the text is
selected. So it seems the "onblur" does not really finish until the
document or window loses focus. Also, if I put focus on the textarea then
change applications, the onblur fires twice so I have to deal with two
alerts.

I tried a few work arounds, they were all messy and very unsatisfactory.
I'd just avoid this altogether and validate the textarea on some other
event.

Rob.


Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Jul 23 '05 #3

P: n/a
Roger Withnell wrote:
Rob

Thanks for your thorough and extensive analysis.

My problem is that the form is putting the text into a database table field
which has a finite size. So I must stop the user entering more characters
that the database table wants. I don't want to discard the text that is
over the limit. I want to give the user the choice to adjust his text
within the limit set by the database table.

How do you suggest I achieve this?


The typical method is to validate the form when the user
submits it, firstly at the client then at the server. You
must do server validation as you have no way of knowing if
your validation has actually been run on the string
submitted to the server (user may have JS turned off, may be
spoofing your server by creating their own submit, modifying
the URI parameters manually, etc.)

So a good way is to put an alert right next to the text
field that shows up if they don't do it right. Hide the
message using an onload function, that way if JS is turned
off the message shows all the time. If the user gets it
wrong, show the message. When they get it right, hide it
again. This way, you don't care how often the onblur fires
since the action it takes is quite innocuous.

Another way would be to show the error text in a soft colour
(say light blue or pink), then if they get it wrong, change
the style to bold red.

I haven't played with the layout, but immediately to the
right is usually best.

Minimial implementation follows:

<html>
<head>
<title>Entry Error Play</title>
<script type="text/javascript">
function boxCheck(a) {
var aErr = document.getElementById('aTAerror');
if (a.value.length > '3') {
alert('Ooops');
aErr.style.visibility = 'visible';
} else {
aErr.style.visibility = 'hidden';
}
}

function hideError() {
document.getElementById('aTAerror').style.visibili ty =
'hidden';
}
</script>

</head>

<body onload="hideError();">

<form name="me2" action="">
<textarea name="aTA" value="start_value"
onblur="boxCheck(this.form.aTA);
"></textarea>
<div id="aTAerror"
style="color: red;
font-weight: bold;
font-family: arial, sans-serif;">
You must enter a maximum of three characters</div>
</form>
</body>
</html>

Jul 23 '05 #4

P: n/a
RobG wrote:

[snip]
alert('Ooops');

[snip]

Ooops!! Get rid of the rotten alert, it was there for debug
only - it ensures IE traps you in the text area.

The checkBox function should have been:

function boxCheck(a) {
var aErr = document.getElementById('aTAerror');
if (a.value.length > '3') {
aErr.style.visibility = 'visible';
} else {
aErr.style.visibility = 'hidden';
}
}
Rob.
Jul 23 '05 #5

P: n/a
Roger Withnell wrote:
Rob

Thanks for your thorough and extensive analysis.

My problem is that the form is putting the text into a database table field
which has a finite size. So I must stop the user entering more characters
that the database table wants. I don't want to discard the text that is
over the limit. I want to give the user the choice to adjust his text
within the limit set by the database table.

How do you suggest I achieve this?


Part deux:

I also tried using <label> as suggested by Mike Winter in a
previous thread(1), however it doesn't seem to have a style
property that can be manipulated. The OP of that thread
settled for using <span> rather than <div> when adding a
caption to a textarea.

Your choice - Rob.

1.
Mike wrote:

As the text probably qualifies as a label, the LABEL
element would be the best to use:

<label for="myInput"><input id="myInput" type="checkbox" ...>
Your text here</label>

All DOM-supporting browsers should access that label text with:

inputObj.nextSibling.data

(Verified with the latest versions of Opera, IE, Mozilla,
Netscape, and Firefox)

When you change the value, remember to add a space before
the text so that it doesn't appear flush next to the
checkbox.
Jul 23 '05 #6

P: n/a
On Fri, 08 Oct 2004 03:55:48 GMT, RobG <rg***@iinet.net.auau> wrote:

[snip]
I also tried using <label> as suggested by Mike Winter in a
previous thread(1), however it doesn't seem to have a style
property that can be manipulated.
What are you trying to manipulate, the LABEL element or its contents?
LABELs certainly can be styled, unless you're using a less-than-dynamic
browser (which shouldn't include the "major" modern ones).
The OP of that thread settled for using <span> rather than
<div> when adding a caption to a textarea.


Yes. The OP never said why.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #7

P: n/a
Michael Winter wrote:
[snip]
What are you trying to manipulate, the LABEL element or its contents?
LABELs certainly can be styled, unless you're using a less-than-dynamic
browser (which shouldn't include the "major" modern ones).


I tried playing with the label.style in Firefox, but it just kept
returning "undefined". I had no problem applying an in-line style but
there doesn't seem to be an interface to access it.

I wanted to either toggle it's visibility or colour but couldn't seem to
access it the same way you can manipulate other elements.

Rob.
Jul 23 '05 #8

P: n/a
On Sat, 09 Oct 2004 00:41:49 +1000, RobG <rg***@iinet.net.auau> wrote:
I tried playing with the label.style in Firefox, but it just kept
returning "undefined". I had no problem applying an in-line style but
there doesn't seem to be an interface to access it.


<label for="myInput">My label:
<input id="myInput"
onfocus="this.parentNode.style.color = '#0000ff';"
onblur="this.parentNode.style.color = '';">
</label>

Firefox 0.9.3 has no problem with the above. The text, "My label:", does
turn blue as a result of giving focus to the label, whether by clicking on
the component or on the label itself.

Are you sure you aren't making some silly mistake resulting in you trying
to get the style object on a non-element node?

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #9

P: n/a
Michael Winter wrote:
[snip]
Are you sure you aren't making some silly mistake resulting in you
trying to get the style object on a non-element node?

Mike


Very likely. I was using nextSibling.style, as nextSibling.data
returns the text. It never occured to me to use parentNode, though
clearly the structure of the HTML indicates that would have been
correct (20/20 hindsight, eh?).

I guess nextSibling is actually getting the text element of the label,
whereas I should have been playing with the style of the label itself.

I'll have another play in the morning ... kinda late now.

Cheers, Rob.
Jul 23 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.