Form validation help

V

Vinny

A customer wants me to convert a VB app I wrote for them into a web app
for remote users to do data entry.

So, I'm writing a small ASP program which prompts the user for data,
much like a VB program. I would like to interactively validate the data
as they are entering it, rather than waiting until they submit the
form. So, I am doing something like this (this is a very simple
example):

<head>
<script language=javascript>


function validatefield1()
var i;
i = document.myForm.field1.value
if ( i < 10 or i > 20 ) {
alert("please enter a # between 10 and 20!");
document.getElementByID('field1').focus();
return false;
}
return true;
}


function validatefield2()
var i;
i = document.myForm.field2.value
if ( i < 20 or i > 30 ) {
alert("please enter a # between 20 and 30!");
document.getElementByID('field2').focus();
return false;
}
return true;
}


</script>
</head>
<body>
<form name=myForm id=myForm method=post action='/nextpage.asp'>
Field1: <input type=text size=2 id=field1 name=field1
onblur='validatefield1();'>
Field2: <input type=text size=2 id=field1 name=field1
onblur='validatefield2();'>
</form>
</body>

Here is the problem:


By default the first field has focus. If I press tab to bypass it
without entering anything, focus shifts to field2 immediately. The
onblur event fires, which checks the value in field1, sees it is
invalid, so prints an error message and resets the focus to field2.

Naturally, this causes field2 to lose focus. This causes field2's blur
event to kick of, which causes an error (since the field is blank),
printing an error, setting focus back to field2.

The effect is an endless loop of error messages.

I've tried other combinations of events, such as ondeactivate, but they
all result in the same behavior.


Why does the focus shift from field1 to field2 prior to the onblur
event completing?


Can someone explain the proper sequence of event processing on ASP
forms? When I press tab in field1, why does focus shift to field2 prior
to the onblur event for field1 completing? I can't seem to find this
documented anywhere in the msdn documentation to explain how events are
sequenced on IIS forms.


Alternatively, can someone suggest which event I would use to
accomplish what I'm trying to do? I've read the newsgroup and people's
comments about not using the onblur event, but I'd prefer to
interactively validate data, rather than waiting until the form is
submitted which I think is messy and unprofessional, compared to the VB
apps I've written. Plus the customer wants me to keep the web page
operationally identical to the VB app, and the VB app validates data at
the point of entry.


Thanks
Vin
 
V

VK

i = document.myForm.field1.value

This is a call for troubles, especially in IE. Better use the
conventional form addressing syntax. And always use "var" in variable
declaration. First you're avoiding global variable while you need a
local one. Secondly add <div id="i"></div> into your page for a sample
of other bad things it may lead to.

var v = document.forms['myForm'].elements['field1'].value;
if ( i < 10 or i > 20 ) {

There is not "or" operator in JavaScript. It's called "||" here.

if (v<10 || v>20) {

All together:

function validatefield1() {
var fld = document.forms['myForm'].elements['field1'];
var v = fld.value;
if (v<10 || v>20) {
alert('wrong input');
fld.select();
fld.focus();
}
}

By default the first field has focus. If I press tab to bypass it
without entering anything, focus shifts to field2 immediately. The
onblur event fires, which checks the value in field1, sees it is
invalid, so prints an error message and resets the focus to field2.

Naturally, this causes field2 to lose focus. This causes field2's blur
event to kick of, which causes an error (since the field is blank),
printing an error, setting focus back to field2.

The effect is an endless loop of error messages.

I've tried other combinations of events, such as ondeactivate, but they
all result in the same behavior.


Why does the focus shift from field1 to field2 prior to the onblur
event completing?

I donno - I guess the main part of errors came from "or". Overall you
have no way to guess why did user came to some field and why left it
unfilled for another field. Maybe she's using tab to navigate and she
wants to fill some underlaying fields first. Maybe she got blink in her
AIM so she needs to switch the window. Maybe she started to fill her
account info and she needs to look at another file for the last number.
It is futile tu guess and it is *highly* irritating to users to be
alert(ed) on each onblur.

I would suggest to drop this approach all together. You better put some
visual marks (say green) near each properly filled field as long as
your user navigates from field to field. And onsubmit you do one more
final check and place say red marks near all unfilled or unproperly
filled fields. Your users will just love this and its author :)
 
M

Michael Winter

i = document.myForm.field1.value

[...] And always use "var" in variable declaration.

The OP did. In both functions, it was the line prior to the one you
quote above.

[snip]
var v = document.forms['myForm'].elements['field1'].value;

When property names conform to the Identifier production, dot notation
will suffice:

var v = document.forms.myForm.elements.field1.value;

Better yet, avoid resolution of the control altogether:

<input name="field1" size="2" onchange="validateField1(this);">

function validateField1(control) {
var v = +control.value;

if ((v < 10) || (v > 20)) {
alert('Please enter a number between 10 and 20.');
if (control.focus)
control.focus();
return false;
}
return true;
}

By the way, it goes without saying that names like 'field1' are terrible.

[snip]

Which is why it's imperative to avoid the blur event when messing with
control focus. In fact, the blur event should be avoided in general for
validation purposes as warnings can become, from the user's perspective,
harassment.

Use the change event, as illustrated above. To catch omitted fields,
also validate using the submit event.

It doesn't. The listener for the first control does complete, but the
loss of focus during the execution of that listener queues another blur
event. When the function returns, the event is dispatched into the
document tree, calling the other listener.

[snip]

Mike
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top