focus() problem with Netscape <input onBlur>

[CES]

All,

I'm having a problem returning focus back to an input field in Netscape. The
code works in IE and Opera but not in netscape6+.

Basically I have a function that is called upon exiting a form field, if the
value validates properly it returns true and calls another function, if it
doesn't validate the field it returns false and I want to give focus back to
the sender and highlight all of the text in the field.

The problem is that while IE and opera return the curser back to the field -
Netscape ignores the focus statement (I still can't find any examples as to
how to return the curser and highlight the text in the field).

Any suggestions as to what I'm doing wrong will be appreciated.

CES

function fExitField(send er){

returnedValue = fValidateData(s ender);

if(returnedValu e == true){ //

fRemoveAsterisk (sender);

}

if(returnedValu e == false){

document.forms[fGetFormName(se nder)].elements['id_'
+ sender].focus(); // FYI I have multiple forms an the page -
fGetFormName(se nder) returns the name of the form that contains the element.

alert("Improper Format");

}

}

This is an example of my tag structure:

<input id="id_cName" name="cName" type="text" maxlength="50"
onFocus="fEnter Field('cName')" onKeyDown="fKey Press('cName')"
onKeyUp="fKeyPr ess('cName')" onBlur="fExitFi eld('cName')" tabindex="1" />

[VK]

Js Almighty,
Anyone monitors this group?

1.) ID vs. NAME
2.) Full DOM path by 3W vs. Shortened Path by IE

Cane we make a good FAQ on it?
With a daily repost?

[Lasse Reichstein Nielsen]

"CES" <No**@noSpam.co m> writes:

I'm having a problem returning focus back to an input field in Netscape. The
code works in IE and Opera but not in netscape6+. Basically I have a function that is called upon exiting a form field, if the
value validates properly it returns true and calls another function, if it
doesn't validate the field it returns false and I want to give focus back to
the sender and highlight all of the text in the field.

Mozilla/Netscape 6+ has a quirk: If you try to change the focus, it triggers
the onblur event *before* changing the focus. So when you set focus in the
onblur handler, the real focus change happens afterwards anyway.

A known solution is to delay the setting of the focus, i.e., instead
of foo.focus(), you do
setTimeout(func tion(){foo.focu s();},10);

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Lee]

CES said:

All,

I'm having a problem returning focus back to an input field in Netscape. The
code works in IE and Opera but not in netscape6+.

Basically I have a function that is called upon exiting a form field, if the
value validates properly it returns true and calls another function, if it
doesn't validate the field it returns false and I want to give focus back to
the sender and highlight all of the text in the field.

The problem is that while IE and opera return the curser back to the field -
Netscape ignores the focus statement (I still can't find any examples as to
how to return the curser and highlight the text in the field).

Any suggestions as to what I'm doing wrong will be appreciated.

CES

function fExitField(send er){

returnedValue = fValidateData(s ender);

if(returnedValu e == true){ //

fRemoveAsterisk (sender);

}

if(returnedValu e == false){

document.forms[fGetFormName(se nder)].elements['id_'
+ sender].focus(); // FYI I have multiple forms an the page -
fGetFormName(s ender) returns the name of the form that contains the element.

alert("Improper Format");

}

}

1. Don't pass the name of the field around. Pass a reference
to it, and you won't have to worry about which form it's in.

2. Don't validate onBlur. There are too many unexpected things
that can cause a field to lose focus. Being forced to click
the OK button of an alert, for instance.

3. Never test a logical value for equality to true or false,
and certainly never test against both cases.
If it's true, it's true, otherwise, it's false.

4. Don't name all of your functions with a lowercase "f" prefix.
If it has parentheses after it, it's a function.
function fExitField(send er){
if(fValidateDat a(sender)){
fRemoveAsterisk (sender);
}else{
alert("Improper Format");
sender.focus();
}
}
<input id="id_cName" name="cName" type="text" maxlength="50"
onFocus="fEnter Field(this)" onKeyDown="fKey Press(this)"
onKeyUp="fKeyPr ess(this)" onChange="fExit Field(this)" tabindex="1" />

[Stephen Poley]

On 1 Dec 2003 15:38:58 -0800, Lee <RE************ **@cox.net> wrote:

2. Don't validate onBlur. There are too many unexpected things
that can cause a field to lose focus. Being forced to click
the OK button of an alert, for instance.

So how would you do it? Personally, as a user, I'd prefer to get
feedback step-by-step, rather than waiting until I get to the end of the
form.

What arguably is a problem is the combination of onBlur and validation
results via an alert box. If one is doing onBlur validation, it's better
to write error messages in the HTML, next to the field concerned. Leave
the alert boxes until one gets to onsubmit.

I'm also not sure that forcing the focus back to the field concerned is
a good idea with onBlur validation. Maybe a colleague is looking up
(say) our contract number while I get on with filling in the rest of the
form. I don't want to be blocked from doing so.

--
Stephen Poley

[Lee]

Stephen Poley said:

On 1 Dec 2003 15:38:58 -0800, Lee <RE************ **@cox.net> wrote:

2. Don't validate onBlur. There are too many unexpected things
that can cause a field to lose focus. Being forced to click
the OK button of an alert, for instance.

So how would you do it? Personally, as a user, I'd prefer to get
feedback step-by-step, rather than waiting until I get to the end of the
form.

use onChange, instead of onBlur

[Dr John Stockton]

JRS: In article <bq*********@dr n.newsguy.com>, seen in
news:comp.lang. javascript, Lee <RE************ **@cox.net> posted at Mon,
1 Dec 2003 15:38:58 :-

1. Don't pass the name of the field around. Pass a reference
to it, and you won't have to worry about which form it's in.
In the page I'm currently working on, there can be several forms with
the same structure. Here it is convenient to use the field name
qualified by the form name; thus, identical parts of different forms ban
use the same name.

There is much to be said for limiting the scope of identifiers; for
example, it reduces the risk of inadvertently writing to the wrong form.
4. Don't name all of your functions with a lowercase "f" prefix.
If it has parentheses after it, it's a function.

If it has a left parenthesis, it needs to be a function. That means
that *either* it is a function, *or* it is a mistake. The f-notation
may help in avoiding the latter.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Stephen Poley]

On 2 Dec 2003 09:14:53 -0800, Lee <RE************ **@cox.net> wrote:

Stephen Poley said:

On 1 Dec 2003 15:38:58 -0800, Lee <RE************ **@cox.net> wrote:

2. Don't validate onBlur. There are too many unexpected things
that can cause a field to lose focus. Being forced to click
the OK button of an alert, for instance.

So how would you do it? Personally, as a user, I'd prefer to get
feedback step-by-step, rather than waiting until I get to the end of the
form.

use onChange, instead of onBlur

Yes, I suppose so. The one thing you can't then do is replace the small
civilised "required" marker with a bold red "ERROR - You must enter
this" marker when the user tabs through a field without entering
anything. But perhaps that's not important enough to be worth worrying
about.

--
Stephen Poley

[Lee]

Stephen Poley said:

On 2 Dec 2003 09:14:53 -0800, Lee <RE************ **@cox.net> wrote:

Stephen Poley said:

On 1 Dec 2003 15:38:58 -0800, Lee <RE************ **@cox.net> wrote:

2. Don't validate onBlur. There are too many unexpected things
that can cause a field to lose focus. Being forced to click
the OK button of an alert, for instance.

So how would you do it? Personally, as a user, I'd prefer to get
feedback step-by-step, rather than waiting until I get to the end of the
form.

use onChange, instead of onBlur

Yes, I suppose so. The one thing you can't then do is replace the small
civilised "required" marker with a bold red "ERROR - You must enter
this" marker when the user tabs through a field without entering
anything. But perhaps that's not important enough to be worth worrying
about.

Yes. Consider how annoying it is to tab down to the field whose value
you happen to have in your paste buffer at the moment, only to have
every field along the way scream at you.

[Stephen Poley]

On 2 Dec 2003 13:16:00 -0800, Lee <RE************ **@cox.net> wrote:

Stephen Poley said:

On 2 Dec 2003 09:14:53 -0800, Lee <RE************ **@cox.net> wrote:

Stephen Poley said:

On 1 Dec 2003 15:38:58 -0800, Lee <RE************ **@cox.net> wrote:

>2. Don't validate onBlur. There are too many unexpected things
> that can cause a field to lose focus. Being forced to click
> the OK button of an alert, for instance.

So how would you do it? Personally, as a user, I'd prefer to get
feedback step-by-step, rather than waiting until I get to the end of the
form.

use onChange, instead of onBlur

Yes, I suppose so. The one thing you can't then do is replace the small
civilised "required" marker with a bold red "ERROR - You must enter
this" marker when the user tabs through a field without entering
anything. But perhaps that's not important enough to be worth worrying
about.

Yes. Consider how annoying it is to tab down to the field whose value
you happen to have in your paste buffer at the moment, only to have
every field along the way scream at you.

Granted. You've convinced me.

--
Stephen Poley